[systemd] Impossible de booter (résolu)

[neves]

Bonjour,

Suite au passage au noyau 3.6.4, je n'ai plus de son sur mon système (j'utilise ALSA, pas PulseAudio). Après une recherche sur Internet, j'ai trouvé ce message :

https://bbs.archlinux.org/viewtopic.php?pid=1184951

qui semble correspondre à mon problème, et dont la résolution passe par l'utilisation de systemd pour booter. Bref, comme il va falloir y passer, je me suis dis que c'était l’occasion. Mon rc.conf est à jour et "éclaté" comme il faut. J'édite donc le menu.lst de mon grub pour ajouter init=/usr/lib/systemd/systemd à la ligne du kernel et reboot. Et là, c'est le drame : plusieurs messages [FAILED] défilent, je n'ai pas le temps de noter les premiers. Ceux que je peux lire m'indiquent que systemd n'arrive pas à monter mes partages samba. Ça ne me semble pas vraiment grave. Par contre, systemd finit par s’arrêter sur :

[...]
[OK] Mounted /boot
[OK] Reached target Sound Card

avec comme erreur "timed out waiting for device /dev/mapper/array\2xdroot.device", et me lance un "emergency shell", débutant par une dizaine de nouvelles lignes d'erreurs me parlant de "Dependancy failed" sur divers services systemd. (D'ailleurs quand je tape reboot ou shutdown -r now dans ce shell, systemd n'arrive pas à rebooter et me sort un message d'erreur parlant de timeout sur /dev/initctl, c'est bien fait...).

Bref, /dev/mapper/array-root c'est mon raid logiciel, déclaré ainsi dans /etc/fstab :

# all vgroup is encrypted
/dev/mapper/vgroup-root / ext4 defaults 0 1
/dev/mapper/vgroup-home /home ext4 rw,nosuid,nodev,exec,auto,nouser,async 0 0
/dev/mapper/vgroup-swap none swap sw 0 0
# TODO: encrypt /tmp in ramfs
/dev/mapper/vgroup-tmp /tmp ext4 rw,nosuid,nodev,exec,auto,nouser,async 0 0
UUID=84b11fac-30fa-4c33-bb8d-b5fef0345aea /boot ext4 rw,nosuid,nodev,noexec,auto,nouser,async 0 0
# RAID
/dev/mapper/array-root /media/raid ext4 rw,exec,auto,nouser,async,nosuid,nodev 0 0

Le chiffrement (qui ne concerne pas le raid) se passe au niveau de l'initramfs, avec "encrypt" et "lvm2" dans les HOOKS de /etc/mkinitcpio.conf. Le chiffrement ne semble pas poser de problème, le mot de passe est bien demandé avant systemd (directive "cryptdevice" dans le menu.lst de grub). Je passe donc les détails de lvm concernant "vgroup" ici.

En ce qui concerne le raid, voilà mon fichier /etc/mdadm.conf :

ARRAY /dev/md0 level=raid5 num-devices=4 metadata=0.90 spares=1 UUID=9acd4937:dae98ffe:7eb49b9a:eebb9f5f

J'ai donc un physical device lvm "/dev/md0" qui contient un logical device "/dev/array/root", ce qui donne le /dev/mapper/array-root qu'on retrouve dans /etc/fstab. Tout ça marche très bien depuis quelques années. Mon système est entièrement à jour et fonctionne sans aucun autre problème quand je n'ai pas à booter avec systemd.

J'ai suivis les pistes données ici https://bbs.archlinux.org/viewtopic.php?id=146982 sans succès.

Mes questions :
- Une idée de pourquoi systemd ne monte pas correctement le raid ?
- Comment puise-je faire enregistrer les messages de boot de systemd quelque part pour pouvoir tous les lire ?


Maintenant, le paragraphe philosophique :

Je trouve qu'ArchLinux a complétement perdu son principe "KISS" avec le temps, j'aimais bien la simplicité d'avoir toute la configuration dans rc.conf, comme j'aimais bien l'utilisation d'un système de boot éprouvé, fiable et simple. Suite à mon problème, j'ai effectué des recherches sur Internet et pu lire de nombreux autres problèmes divers et variés liés à systemd (pour donner un exemple, celui de quelqu'un qui passe à systemd, ça marche, une semaine plus tard il met à jour systemd et sa machine ne boot plus). Aujourd'hui, avec systemd, je n'ai aucune idée de comment bootera mon système, si un jour il arrive à booter, même si je ne suis pas contre le changement et que je veux bien apprendre comment ça marche. Le nombre de problèmes qu'apporte systemd par rapport au faible gain de performance (quelques secondes gagnées au démarrage, parfois) me confirme dans l'idée qu'ArchLinux aurait du refuser l'utilisation de ce bloatware. Debian est plus KISS qu'ArchLinux, actuellement.

Merci.

[tuxce]

Salut, une des particularités de systemd est qu'il lance tout ce qu'il peut lancer le plus tôt possible. Pour ton cas, le raid ne doit pas encore être disponible quand systemd essaie de monter le volume.
Tu peux essayer en rajoutant x-systemd.automount aux options de la ligne du fstab pour ne le monter qu'au premier accès (j'imagine une fois dans la session utilisateur)

Pour les messages du boot, tu peux sois activer syslog et tu les auras dans les logs habituels, soit tu utilises journalctl -b.

En ce qui concerne le paragraphe philosophique, comme beaucoup, tu confonds simple pour l'utilisateur et simple dans le sens sans ajout, patch ou autres complications pour rendre les choses ... simples.
Si tu recherches des sujets sur des personnes ne pouvant pas démarrer sur initscripts, t'en trouveras, de même que tu trouveras aussi des cas où ça fonctionnait et plus du tout après une mise à jour.
Ensuite, ce qu'apporte systemd n'inclue pas la vitesse de démarrage, celle ci n'est qu'une conséquence du démarrage en parallèle et n'est pas forcément observable (si quelqu'un démarrait 2 services avant, le boot sera même plus lent)
Après, bloatware ou pas, c'est des discussions sans fin, il y en a eu des tonnes avant et c'est sûrement pas après que ça changera grand chose (surtout entre de simples utilisateurs) !

[neves]

Merci tuxce pour ta réponse.

x-systemd.automount a résolu ce premier problème, j'arrive maintenant à mon interface graphique, X se charge correctement (après moult warning de systemd qui défilent trop rapidement - dont ALSA... on va finir par nous imposer PulseAudio c'est ça ?). Maintenant, lorsque je me log et que je tape correctement mon mot de passe, l'interface reste grise et rien ne se passe. Pareil en console, si je me log via CTRL+ALT+F1, je n'obtiens pas de shell. C'est quand même quelque chose de primordial ! Qu'il y ait des erreurs, soit, mais que je puisse obtenir un shell pour voir ce qu'il se passe c'est la seule brique vitale qu'on demande au logiciel qui boot notre OS !

Après reboot sans systemd, je n'ai aucun log dans /var/log. journald m'informe qu'il n'arrive toujours pas à monter mon raid, après ma connexion utilisateur :

Nov 05 07:30:48 squirrel systemd[1]: Socket service syslog.service not loaded, refusing.
Nov 05 07:30:48 squirrel systemd[1]: Failed to listen on Syslog Socket.
[...]
Nov 05 07:30:51 squirrel systemd[1]: syslog-ng.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Nov 05 07:30:51 squirrel systemd[1]: Unit syslog-ng.service entered failed state
[...]
Nov 05 07:30:52 squirrel systemd[1]: alsa.service: control process exited, code=exited status=1
Nov 05 07:30:52 squirrel systemd[1]: Failed to start LEGACY unit for "alsa" rc script.
Nov 05 07:30:52 squirrel systemd[1]: Unit alsa.service entered failed state
[...]
Nov 05 07:31:04 squirrel systemd-logind[600]: New session 1 of user XXX.
Nov 05 07:31:04 squirrel systemd-logind[600]: Linked /tmp/.X11-unix/X0 to /run/user/1003/X11-display.
[...]
Nov 05 07:33:49 squirrel systemd[1]: Job dev-mapper-array\x2droot.device/start timed out.
Nov 05 07:33:49 squirrel systemd[1]: Timed out waiting for device dev-mapper-array\x2droot.device.
Nov 05 07:33:49 squirrel systemd[1]: Dependency failed for /media/raid.
Nov 05 07:33:49 squirrel systemd[1]: Job media-raid.mount/start failed with result 'dependency'.
Nov 05 07:33:49 squirrel systemd[1]: Job dev-mapper-array\x2droot.device/start failed with result 'timeout'.

Bref, systemd n'arrive toujours pas à monter mon raid lorsque je me connecte, et du coup il bloque tout le reste.

Je constate d'ailleurs une erreur avec syslog, ce pourquoi il n'a rien loggé (ça parle d'un argument invalide, pourtant valide sans systemd...). Sans avoir vérifié, je suppose qu'au moment où systemd a voulu lancer syslog, il n'avait pas encore chargé le réseau, et comme mon syslog écoute sur le réseau pour recevoir des messages d'autres machines...

J'investiguerais dans la semaine, là je n'ai pas le temps de faire joujou avec ce jouet cassé. Retour en 3.6.5-1 toujours sans son avec ALSA.

Sérieusement, ce "truc" a été testé sur plus de 3 machines ? Comment ça se fait que sur une machine qui a quelques années et qui tourne aux petits oignons (aucune erreur/warning au démarrage/à l'extinction, boot en 5 secondes, etc.) sans systemd, je puisse avoir tant de problèmes ? systemd n'est clairement pas assez mature pour passer au stade production.

Concernant la simplicité, je ne pense pas confondre les deux. J'ai l'impression que systemd n'est ni simple pour l'utilisateur ni pour le développeur (en tout cas, certainement pas pour le debuggeur qui cherche à comprendre qui déconne et à quel moment). Par exemple, dire à systemd "ne monte pas mon raid maintenant parce que tu ne sauras pas le faire en utilisant x-systemd.automount" au lieu de lui dire "charge la brique "raid" avant de monter mon raid", ça me semble être un patch "au scotch".
Je ne dis pas que systemd est une mauvaise idée (mouais...), mais en tout cas je suis persuadé qu'il nous a été imposé beaucoup trop tôt (on ne peut pas nier qu'il n'a pas été imposé, où alors on ne met plus à jour sa machine) et que systemd n'est vraiment pas prêt pour remplacer quelque chose d'aussi important que le logiciel qui démarre notre OS.

[tuxce]

Après reboot sans systemd, je n'ai aucun log dans /var/log. journald m'informe qu'il n'arrive toujours pas à monter mon raid, après ma connexion utilisateur :

Ton utilisateur a besoin de /media/raid avant même d'avoir un shell ?
Sinon, t'as essayé en root ? ou il en a besoin aussi ?
Tu n'avais pas un module ou une configuration spécifique pour ton raid ?

Sérieusement, ce "truc" a été testé sur plus de 3 machines ?

Non juste les 2 des devs.

Concernant la simplicité, je ne pense pas confondre les deux.

Si si. Pour garder initscripts, il aurait fallu garder 2 ou 3 softs dépréciés, en patcher d'autres pour qu'il soit compatibles avec ceux qui sont dépréciés, tout ça pour juste reculer le moment où il y aura une migration qui obligatoirement apportera son lot d'erreur pour cause de bugs, mauvaise configuration etc.

Par exemple, dire à systemd "ne monte pas mon raid maintenant parce que tu ne sauras pas le faire en utilisant x-systemd.automount" au lieu de lui dire "charge la brique "raid" avant de monter mon raid", ça me semble être un patch "au scotch".

Je ne connais pas ton raid, je ne pouvais pas te dire autre chose que ça.

je suis persuadé qu'il nous a été imposé beaucoup trop tôt

Ca fait plus d'un an qu'il est dans les dépôts, j'ai vu des migrations plus brutales.

et que systemd n'est vraiment pas prêt pour remplacer quelque chose d'aussi important que le logiciel qui démarre notre OS.

Et pourtant, il en démarre des machines.

[neves]

Ton utilisateur a besoin de /media/raid avant même d'avoir un shell ?

Non

Sinon, t'as essayé en root ? ou il en a besoin aussi ?

Non, pas essayé. Je testerais.

Tu n'avais pas un module ou une configuration spécifique pour ton raid ?

Non, raid software tout ce qu'il y a de plus standard.

Si si. Pour garder initscripts, il aurait fallu garder 2 ou 3 softs dépréciés, en patcher d'autres pour qu'il soit compatibles avec ceux qui sont dépréciés, tout ça pour juste reculer le moment où il y aura une migration qui obligatoirement apportera son lot d'erreur pour cause de bugs, mauvaise configuration etc.

Et pour supprimer initscripts, on ajoute un bloatware, on patch mille softs pour qu'ils fonctionnent avec, on change l'organisation d'un système de fichiers, on change l'âme d'une distrib' (son esprit KISS, son rc.conf, etc.) tout ça pour juste dire que c'est plus moderne comme ça et mieux fait. Je suis sans doute passé à coté d'une info importante comme l'expiration d'initscripts en 2013, toutes les distributions l'utilisant vont arrêter de fonctionner ? Bref, j'ironise, je râle un peu de manière trollesque, mais je me sens de plus en plus mal à devoir utiliser systemd. Mais comme je DOIS l'utiliser, je vais arrêter là et tacher de le faire fonctionner. Tant pis pour initscripts qui a si bien fonctionné pendant des années.

Je ne connais pas ton raid, je ne pouvais pas te dire autre chose que ça.

Ne te méprend pas, je ne te reproche aucunement ton aide, qui a fait avancer le problème. C'est sans doute la seule réponse valable possible, et c'est justement ça qui est moche.

Ca fait plus d'un an qu'il est dans les dépôts, j'ai vu des migrations plus brutales.

Comme par exemple ? Une migration ne devrait jamais être imposée.

Et pourtant, il en démarre des machines.

Pas la mienne. Et toujours moins qu'initscripts

[benjarobin]

Pour syslog-ng tu n'es premièrement pas à jour et/ou tu n'as pas lu le Wiki.
Et je suis désolé mais si c'est comme cela sur tout tes daemons cela ne risque en effet pas de fonctionner

[neves]

Pour syslog-ng tu n'es premièrement pas à jour et/ou tu n'as pas lu le Wiki.
Et je suis désolé mais si c'est comme cela sur tout tes daemons cela ne risque en effet pas de fonctionner

Je suis à jour, comme dit dans mes précédents messages.

J'ai lu le wiki. Concernant syslog, on me dit de faire "systemctl enable syslog-ng" pour l'utiliser. D'accord. Comment j'utilise systemctl sans avoir systemd chargé ?

#> systemctl enable syslog-ng
Operation failed: Invalid argument

[tuxce]

Ca fait plus d'un an qu'il est dans les dépôts, j'ai vu des migrations plus brutales.

Comme par exemple ?

Celle de la fin de HAL par exemple.
Dépréciation de hal, maj de xorg en même temps, gestionnaire de fichier n'ayant pas encore suivi etc.

Une migration ne devrait jamais être imposée.

Elle ne l'est pas. Tu as choisi d'utiliser une distribution qui suit les évolutions et dont les développeurs essaient de ne patcher que le strict minimum. Quand ils ont estimé que ce n'était plus possible de garder le reste, ils ont mis systemd par défaut.

Et pourtant, il en démarre des machines.

Pas la mienne.

Mais si, une fois que tu sauras pourquoi le raid n'est pas reconnu (si root se connecte, ça devrait pas poser de problème), tu feras le nécessaire et à la prochaine migration, tu repartiras de 0

[Getalo]

Bonjour,
juste une remarque : chez moi les tty sont de ctr+alt de F2 à F6 et retour en graphique avec ctr+alt F1

à plus.

[tuxce]

(Comme tu avais édité après, j'avais pas vu)

Et pour supprimer initscripts, on ajoute un bloatware, on patch mille softs pour qu'ils fonctionnent avec, on change l'organisation d'un système de fichiers

Tout ça, c'est en dehors d'Archlinux !
(bloatware donne du poids à l'argument, c'est certain)

on change l'âme d'une distrib' (son esprit KISS, son rc.conf, etc.)

Et du coup, personne ne change rien parce que tu ne vas pas remodifier les softs mis à jour en upstream pour le plaisir de quelques uns.

Je suis sans doute passé à coté d'une info importante comme l'expiration d'initscripts en 2013, toutes les distributions l'utilisant vont arrêter de fonctionner ?

Seul arch l'utilisait.

je râle un peu de manière trollesque

s/un peu//

Tant pis pour initscripts qui a si bien fonctionné pendant des années.

Et qui ne fonctionne plus pour certains et qui ne fonctionnera plus parce qu'il n'y a aucun développeur qui a voulu le reprendre.

[neves]

Bonjour,
juste une remarque : chez moi les tty sont de ctr+alt de F2 à F6 et retour en graphique avec ctr+alt F1

Yeap, j'avais testé de 1 à 6 sans succès : j'ai un tty, je peux entrer mes informations de connexion, mais ça freeze ensuite au moment où je devrais avoir un shell.

[neves]

Impossible d'obtenir un shell en me connectant en root non plus.

J'arrive à avoir un shell si je commente mon raid dans /etc/fstab, ce qui n'est évidemment pas la solution.

Rien dans journald.

Je ne sais même pas quoi regarder.

[tuxce]

Tu peux voir /etc/mdadm.conf, essayer d'assembler manuellement le raid (mdassemble), voir si /dev/mapper/array-root apparaît et s'il se monte manuellement.
Il y aura peut être un message explicite dans le tas.

[neves]

Merci !

En effet, /dev/mapper/array-root n'était pas créé, lvdisplay sortait "Not available" comme status pour ce logical volume.
J'ai donc du booter avec systemd en commentant la ligne du raid dans /etc/fstab, récupérer un shell via CTRL ALT F1 et taper :

systemctl enable lvm.service

puis décommenter la ligne du raid dans /etc/fstab et rebooter.

D'ailleurs, cette commande ne fait-elle que créer un lien symbolique ? Aurais-je pu activer LVM sans avoir à charger systemctl ou pas ?

Je ne pensais pas que le problème pouvait venir de là étant donné que les autres LVM fonctionnaient sans soucis. Mais en fait ils étaient gérés par l'initramfs. L'information est disponible sur le wiki d'ArchLinux anglais :

If you have LVM volumes not activated via the initramfs, enable lvm.service (provided by the lvm2 package):
# systemctl enable lvm

Ce qui est pertinent si on n'imagine pas qu'initramfs se charge de tous les volumes LVM Je vais ajouter l'info sur le wiki d'ArchLinux FR.

J'ai maintenant du son, avec systemd. Il me reste à m'occuper de syslog et des partages samba, à supprimer journald puis à passer en full systemd. Le mois prochain

Pour ma culture personnelle :

- Pourquoi n'ai-je plus de son avec ALSA si je n'utilise pas systemd avec un kernel compilé par Arch depuis 3.6.4 ?
- Pourquoi n'avais-je pas de shell et un OS complétement bloqué lorsque systemd n'arrive pas à monter une partition sans importance, /media/raid ? Il me semble avoir attendu plus longtemps que les 90 secondes du timeout lorsqu'il y a un problème de montage.

[tuxce]

Pour alsa, aucune idée (ou peut être que tu as oss d'installé ?)
Pour le montage, systemd ne peut pas savoir ce qui est nécessaire pour le démarrage, les entrées du fstab ont la même priorité et après 90s, il te donne la main sur un shell de secours.
En ce qui concerne le blocage, tu pourrais creuser un peu plus, mais à ma connaissance, x-systemd.automount fait que systemd ignore le montage jusqu'à ce que le noyau lui indique une tentative d'accès, donc sauf bug, s'il essaie de le monter, c'est qu'il y a un accès (tu as peut être un script qui fait un test quelconque sur un fichier dans /media/raid), par contre, là, sans connaître la nature de l'accès, on peut pas aller très loin.

[neves]

Hum j'ai alsa-oss installé, ça pourrait être la cause ?

Pour le blocage, je viens de voir que j'ai un script (d'un logiciel installé sur cette partition, ICC) sourcé dans mon .zshrc, pour définir des variables d'environnement. J'imagine que c'est le coupable de l'accès à /media/raid à chaque ouverture de shell, donc