Sylvain Blandel a écrit 248 commentaires

La réponse donnée sur l'autre site n'est finalement que l'application d'un conseil donné ici : modifier manuellement le fichier grub.cfg pour y ajouter une entrée de démarrage.

Quelques remarques cependant :

Il est possible que vous n'utilisiez pas msdos mais sda (plus rare me semble-t-il)

Il me semble que ce sont deux thématiques différentes : « msdos » est un schéma de partitionnement du disque dur, l'autre schéma possible est « gpt ». L'utilisation de « sd× » ou de « hd× » pour désigner les disques durs est fonction du systèmes d'exploitation. Je suis très étonné de voir la vieille notation « hd× » pour un système qui utilise Grub2 (qui doit donc être récent).

les lignes insmod part_msdos et set root='hdo,msdos6' seront donc à modifier en utilisant le mot "sda"

Les utilisateurs d'un disque dur partitionné suivant le schéma « gpt » utiliseront insmod part_gpt ainsi que set root='hd0,gpt6'

Euh … set root='hdo,msdos6' … hdo ??? La lettre « o » ??? Sainte Merde ! Il y a combien de disques durs dans ta machine ?

La ligne insmod btrfs peut spécifier un autre système de fichiers (ext2 par exemple).

La liste des modules disponibles est dans le répertoire /boot/grub/ Ce sont les fichiers en .mod. On peut en mettre beaucoup plus que nécessaire :

    insmod btrfs
    insmod ext2
    insmod fat
    insmod zfs
    insmod reiserfs

On peut même mettre les deux schémas de partitionnement, ça ne pose pas de problème :

    insmod part_gpt
    insmod part_msdos

il me semble que grub vient avec une commande update-grub

Il me semble que la commande update-grub est un script qui ne contient qu'une seule ligne, et que cette ligne est :

grub2-mkconfig -o /boot/grub/grub.cfg


si les outils automatiques ne fonctionnent pas tu peux aussi editer le fichier de config à la main pour copier/coller l'existant et changer le nom du noyau qui est appelé

Entièrement vrai. De très nombreux tutoriels déconseillent d'éditer manuellement le fichier /boot/grub/grub.cfg … c'est pourtant ce que je fais régulièrement. Après avoir fait une copie de sauvegarde du fichier grub.cfg initial, je bricole ce fichier.

Il est préférable de faire des copies de sauvegarde de ton grub.cfg lorsque tu le modifies. En effet, selon les distributions, une mise-à-jour de grub ou du noyau peut générer un nouveau grub.cfg et écraser tes paramétrages personnels.

Remarque : chez moi, le fichier grub.cfg n'est pas dans le répertoire /boot/grub2/ mais dans /boot/grub/ J'imagine que cela dépend des distributions.

Des prédictions pour l'année 2015 ? Des recommandations de sujets pour l'écriture de dépêches collaboratives ?

Un sujet pour 2015 : quel avenir pour Devuan (le fork de Debian sans systemd) ?

• devuan.org
• Journal du 19 octobre 2014 : Un fork de Debian à cause de systemd ?
• Journal du 29 novembre 2014 : Devuan forks Debian : un choc, ou c'était inévitable ?

En février 2014, Debian a adopté systemd comme système d'initialisation par défaut sur les architectures basées sur le noyau Linux. Cette décision fut prise après de trèèèèès longs débats.

9 mois plus tard, des discussions portent sur le support simultané de plusieurs systèmes d'init. En effet, une Résolution Générale est actuellement votée par les contributeurs du projet Debian, le vote se clôture dans une semaine (le 19 novembre 2014).

Bonjour.

J'ai l'extinction du PC qui se fait immédiatement contre 1 ou 2 secondes avant. J'aimerais donc savoir si c'est normal ou s'il y a un problème. Comme je peux savoir si l'extinction s'est faite comme il faut ?

En regardant les logs avec l'outil journalctl -b

La commande journalctl -b 0 fournit tous les logs de l'utilisation actuelle de l'ordinateur (du dernier démarrage jusqu'à maintenant).
La commande journalctl -b -1 fournit tous les logs de l'avant-dernière utilisation de l'ordinateur (du démarrage jusqu'à l'arrêt).
La commande journalctl -b -2 fournit tous les logs de l'avant-avant-dernière utilisation de l'ordinateur (du démarrage jusqu'à l'arrêt)
La commande journalctl -b -3 fournit tous les logs de l'avant-avant-avant-dernière … Bref, je pense que tu as compris :o)

Jette également un coup d'œil sur la commande journalctl --list-boots

Plus d'infos sur ce lien (voir également la page de manuel).

au démarrage il me sort "start a job for /dev/… (25 s / 1 m 30s)" …
(et oui ça a bien duré 1 m 30 sec. Aucune explication de ce qu'est ce truc qui ressemble plus à un timer qu'à autre chose).

Effectivement, c'est un timer. Une unité ne démarre pas, et lorsque la durée TimeoutStartSec est écoulée, systemd considère cette unité comme défaillante (voir également DefaultTimeoutStartSec). Ces durées sont, par défaut, de 90 secondes, cela correspond à ton cas.

Pour diagnostiquer ce qui empêche ta machine de démarrer, tu peux utiliser journalctl avec les options suivantes :

• -p pour filtrer les logs selon leurs criticités,
• -b pour filtrer les logs par démarrage.

Une fois que tu as identifié l'unité défaillante, tu peux filtrer les logs pour n'avoir que ceux de cette unité, avec journalctl -u machin.unité

Ces différentes options de journalctl sont cumulables.

Salut.
Tu devrais pouvoir contrôler la rotation de tes ventilateurs avec les outils lm_sensors et fancontrol.

Ensuite, le fait aussi que personne ne s'intéresse à upstart […]

Sur la liste de discussions upstart-devel, il n'y a eu qu'un seul mail posté entre le 18 septembre 2014 et aujourd'hui (20 octobre 2014). Un seul mail en un mois …

Canonical a décidé de s'appuyer sur systemd pour les prochaines versions d'Ubuntu. Pendant combien de temps cette entreprise investira-t-elle des moyens dans le développement d'Upstart ?

J'ai buté sur le même problème : on peut démarrer un service avec un timer, mais peut-on arrêter un service avec un timer ? Il semblerait que non.

Je m'en suis sorti en créant un second timer, qui lançait un service incompatible avec le premier service.

---

Création d'un timer pour lancer le service steam-cmd.service :

$ cat /etc/systemd/system/steam-cmd.timer


[Unit]
Description=Timer pour lancer steam-cmd.service

[Timer]
OnCalendar=*-*-* 20:00:00
AccuracySec=1s

[Install]
WantedBy=multi-user.target

Ce timer lancera steam-cmd.service à 20h.

---

Création du service stop-steam-cmd.service, incompatible avec steam-cmd.service :

$ cat /etc/systemd/system/stop-steam-cmd.service


[Unit]
Conflicts=steam-cmd.service
Description=stop-steam-cmd.service est en conflit avec steam-cmd.service

[Service]
ExecStart=/usr/bin/echo "Activation de stop-steam-cmd.service"
Type=oneshot

Le lancement de stop-steam-cmd.service va arrêter (« Conflicts ») steam-cmd.service.

---

Création d'un timer pour lancer le service stop-steam-cmd.service :

$ cat /etc/systemd/system/stop-steam-cmd.timer


[Unit]
Description=Timer pour lancer le service stop-team-cmd.service

[Timer]
OnCalendar=*-*-* 02:00:00
AccuracySec=1s

[Install]
WantedBy=multi-user.target 

Ce timer lancera stop-steam-cmd.service à 2h.

---

On valide nos modifications :

$ systemctl daemon-reload

Il ne reste qu'à lancer nos deux timers :

$ systemctl start steam-cmd.timer stop-steam-cmd.timer

et à automatiser leur lancement au démarrage de l'ordinateur :

$ systemctl enable steam-cmd.timer stop-steam-cmd.timer


---

Ça fait beaucoup de choses pour automatiser le lancement et l'extinction d'un service :-) Pour cet exemple, cron est peut-être plus pertinent que les timers de systemd !

Tu peux même intégrer ces options directement dans ton service systemd : Nice et IOSchedulingClass.

Voici un exemple.

Si aucune disposition ne te convient, tu peux construire une disposition adaptée à tes besoins spécifiques. Comment ? En modifiant une disposition de clavier existante. Le programme adéquat s'appelle xmodmap.

Je pars d'une disposition bépo, et voici le fichier /home/toto/.xmodmap.conf qui contient mes modifications :

! Caractère # accessible directement avec AltGr+D :
keycode  31 = d D NoSymbol NoSymbol numbersign numbersign

! Smiley sous les touches C, T, S et N :
keycode 43 = c C NoSymbol NoSymbol copyright U0001F60D
keycode 44 = t T NoSymbol NoSymbol U0001F61E U0001F610
keycode 45 = s S NoSymbol NoSymbol U0001F60A U0001F604
keycode 47 = n N NoSymbol NoSymbol U2661 U2665

! Le séparateur décimal est la virgule (au lieu du point) :
keycode 91 = KP_Delete comma NoSymbol NoSymbol period U202F period

! Espace insécable avec Maj+Espace et AltGr+Maj+Espace :
keycode  65 = space U202F NoSymbol NoSymbol underscore U202F

Pour appliquer les modifications, on tape la commande xmodmap /home/toto/.xmodmap.conf
Plus d'infos sur xmodmap.

J'aurais tellement apprendre dans une dépêche sur wayland que :

Hum … « J'aurais tellement aimé apprendre » plutôt ?

Il y a bien ces schémas des targets qui pourront intéresser quelques lecteurs, mais qui ne répondent pas à ta demande.

Pourrais-tu développer? Je ne comprends pas ce que tu veux dire. Aurais-tu un exemple? Si j'ai compris, un répertoire possède une fonction logique unique avec systemd?

Pré-requis : les fichiers .service fournis par le gestionnaire de paquets sont dans le répertoire /lib/systemd/system/. Les personnalisations réalisées par l'administrateur sont dans le répertoire /etc/systemd/system/

Utiliser des répertoires pour ajouter des dépendances à un service.

Tu souhaites que machin.service dépende de truc.service (c'est-à-dire que le lancement de machin.service lance automatiquement truc.service). Pour se faire, tu as deux méthodes :

La première méthode est de recopier le fichier machin.service dans le répertoire /etc/systemd/system/

$ cp  -a  /lib/systemd/system/machin.service  /etc/systemd/system/

puis d'éditer la copie. Tu ajoutes une ligne « Wants » :

…
[Unit]
Wants=truc.service
…

Cette méthode présente malheureusement un inconvénient : si ton gestionnaire de paquets met à jour le fichier machin.service (dans /lib/systemd/system/), c'est toujours l'ancienne version du fichier (que tu as recopiée dans /etc/systemd/system/) que tu utiliseras.

Pour résoudre ce problème, on utilise une seconde méthode, basée sur les répertoires. On crée un répertoire /etc/systemd/system/machin.service.wants/, et on y met un lien symbolique truc.service qui pointe vers truc.service. Ça donne ceci :

$ ls -l /etc/systemd/system/machin.service.wants/
truc.service -> /lib/systemd/system/truc.service

De cette façon, le lancement de machin.service implique le lancement de truc.service.

---

Utiliser des répertoires pour ajouter des options à un service (sans écraser les options déjà présentes)

Tu souhaites ajouter 3 options au service bidule. Crée le répertoire /etc/systemd/system/bidule.service.d/. Dans ce répertoire, tu crées un fichier perso.conf qui contiendra les 3 options en question :

[Unit]
Description=Service bidule, avec mes personnalisations

[Service]
ExecStartPost=/usr/bin/beep -l100 -r2 
TTYVTDisallocate=no
TimeoutStopSec=30

Ces options se superposeront à celles contenues dans le fichier bidule.service (qui est dans le répertoire /lib/systemd/system/).

---

Pour conclure : remarquez qu'il est possible d'utiliser les fichiers de personnalisation pour créer des dépendances entre services. Pour le service zouzou.service, ça donnerait ceci :

$ cat /etc/systemd/system/zouzou.service.d/perso.conf

[Unit]
Wants=biscotte.service tartine.service
After=biscotte.service
Before=tartine.service

Dans ce cas, le lancement de zouzou.service implique le lancement de biscotte.service et tartine.service. De plus, zouzou.service est lancé après biscotte.service et avant tartine.service.

Systemd permet également de réutiliser les scripts SysVinit existants, voir ce tutoriel : Utiliser un script SysVinit avec systemd.

Si on doit déployer systemd, cela permet de parer au plus pressé : faire fonctionner le système. Plus tard, on peut prendre le temps de remplacer les scripts SysVinit par des fichiers .service qui utiliseront les nombreuses options que propose systemd (premier lien, second lien, troisième lien).

Le réseau social Google+ semble rencontrer un certain succès parmi les développeurs de logiciels libres.

En août 2013, pour annoncer la maintenance étendue du noyau 3.10, Greg Kroah-Hartman avait utilisé son blog personnel (il avait ensuite repris cette annonce sur son compte Google+).

Aujourd'hui, pour annoncer la maintenance étendue du noyau 3.14, Greg n'utilise pas son blog personnel, mais uniquement son compte Google+.

De même, Lennart Poettering a annoncé le mois dernier qu'il communiquait plus souvent via son compte Google+ que via son blog :

Just a small heads-up : I don't blog as much as I used to, I nowadays update my Google+ page a lot more frequently. You might want to subscribe that if you are interested in more frequent technical updates on what we are working on.

Pour les utilisateurs d'Archlinux, le paquet « linux-lts » est déjà passé à cette nouvelle version « LongTerm Stable » du noyau (architecture i686, architecture x86_64).

Bonjour

mon dernier apt-get dist-upgrade m'a fait passer sous systemd

L'installation de systemd a-t-elle désinstallée SysVinit, ou bien as-tu systemd et SysVinit installés simultanément ?

Si les deux sont installés simultanément, tu peux choisir lequel est lancé au démarrage de ton système d'exploitation. De mémoire, le choix se fait avec l'option init=/le/bon/binaire qu'il faut ajouter à la ligne kernel de ton chargeur de démarrage (lorsque cette option n'est pas mentionnée, la valeur par défaut est init=/sbin/init).

Ainsi il suffit d'être ROOT pour arrêter ou relancer un service […] en étant simplement ROOT on peut envoyer […] créer une nouvelle unit.

J'ignore si cela peut résoudre les problèmes que tu rencontres : des utilisateurs non-root peuvent créer, lancer et stopper des unités systemd. Ce fil de discussion en parle, de même que cette page.

Red Hat Enterprise Linux est la première distro entreprise à utiliser systemd

Oui, et d'après cette page, la prochaine version majeure de SUSE Linux Enterprise (la version 12) utilisera elle aussi systemd. On trouve également des références à systemd dans les notes de publication de la (future) version 12 de SUSE Linux Enterprise Server.

Cette évolution n'est guère étonnante : openSUSE utilise systemd depuis novembre 2011.

Que va-t-il rester comme distributions n'utilisant pas systemd par défaut ?

Les distribs Linux s'éloignent de plus en plus des systèmes Unix.

Oui, systemd n'est pas prévu pour les systèmes Unix \(ö)/

OOOOh, c'est beau systemd. C'est simple, ça marche, et quand il y a un problème c'est facile à résoudre.

Le problème qui nous intéressait ici était causé par un changement de système d'init. C'est une opération grave, il ne s'agit pas d'une mise-à-jour de gedit : un élément prépondérant du système est migré d'une technologie à une autre. Cette migration technologique n'a pas, à ma connaissance, d'équivalent (on pourrait peut-être comparer cela aux migrations Gnome 2 → Gnome 3, ou KDE 3 → KDE 4). Vu l'envergure de ce bouleversement, il n'est guère étonnant qu'il y ait des problèmes (surtout que le système d'exploitation utilisé ici est une version unstable).

Puisque nous ne sommes pas habitués à la nouvelle technologie, les problèmes rencontrés nous semblent complexes. Nous perdons l'aisance que nous avions avec la vieille technologie. Faites comme les jeunes : plongez-vous dans les pages de manuel !

Ne va-t-il pas manquer quelques pattes à systemd ?

À systemd lui-même, je pense que non.
Les fichiers de systemd « brut de décoffrage » sont dans /lib/systemd/. Et les modifications réalisées par l'administrateur sont écrites dans /etc/systemd/. Bien évidemment, lorsque le système fonctionne, /etc/systemd/ est prioritaire sur /lib/systemd/.

Pour savoir s'il te manque des trucs dans /etc/systemd/, il faudrait comparer avec une installation fraîche de Debian Sid.

---

Pour rechercher les éventuels messages d'erreur, tu peux consulter le journal avec la commande :

sudo journalctl

Pour n'avoir que les messages depuis le dernier boot, c'est l'option -b. Et pour filtrer les messages importants, c'est l'option -p.

À titre personnel, j'utilise :

sudo journalctl -b -p notice


Bon, il y a du mieux :-)

redémarre en mode normal + single : Le démarrage se fait en mode rescue (?)

C'est normal.
Lorsque l'on démarre son ordinateur avec systemd, single est un raccourci de systemd.unit=rescue.target. Cela démarre le strict minimum, ainsi qu'un shell de secours. Voir ici : lien1, lien2, lien3.

Maintenant que ça fonctionne : tu devrais avoir un démarrage normal en n'utilisant pas single.

---

Je m'attendais à ce que le répertoire /etc/systemd/system/ soit recréé, mais non.

Hum … Je pense que tu devrais le recréer manuellement, même en le laissant vide pour l'instant.

---

Il a fallut sudo /etc/init.d/network-manager restart

Ça, c'est la méthode SysVinit pour démarrer des services. Si tu utilises systemd, il convient d'utiliser la méthode systemd :

1. Dans le répertoire /lib/systemd/system/ cherche le fichier .service de Network Manager (ça devrait être « NetworkManager.service »). Il s'agit d'un fichier texte, tu peux le consulter par curiosité.
2. Pour lancer Network Manager : sudo systemctl start NetworkManager.service
3. Pour automatiser le lancement de Network Manager au démarrage : sudo systemctl enable NetworkManager.service

Cette dernière commande modifiera le contenu du répertoire /etc/systemd/system/. Les modifications apparues signifient que Network Manager est une dépendance du niveau d'exécution « multi-user.target ».

Cette méthode est valable pour tous les services que tu souhaites lancer au démarrage.

---

Il est probable que tu n'aies qu'un seul terminal virtuel, accessible par Ctrl+Alt+F1, et que Ctrl+Alt+F2, Ctrl+Alt+F3, … ne donnent rien. Pour avoir plusieurs terminaux virtuels, voir cette page.

Bon, ben, pas mieux

Argh !

Tant pis, on bourrine : démarre ton système en utilisant le mode recovery de Grub (systemd ne sera pas lancé). Une fois l'ordinateur démarré, fais une copie de sauvegarde du répertoire /etc/systemd/system/, puis recherche et efface dans ce répertoire (et ses sous-répertoires) tout ce qui a trait a dbus.socket et sockets.target. Tu peux même essayer d'effacer tout le contenu de /etc/systemd/system/

Une fois ce ménage réalisé, essaie de démarrer ta machine, avec systemd cette fois-ci. Dans un premier temps, essaie avec le paramètre single (en éditant Grub à la volée).