Bonjour, je travaille sur une debian buster et je suis confronté à un bug de systemd qui me pénalise. Ce bug est censé être corrigé dans la dernière version de systemd, la v252 disponible sur sid. J’aimerais tester cette nouvelle version sans etre obligé d’upgrader tout mon système vers sid (instable) sachant qu’il doit y avoir des contraintes de dépendance vis à vis d’autres packets. Y’a t’il moyen de faire ça? Si oui, quelle est la méthode à adopter?
Merci pour vos conseils
Alors systemd de SID dans Buster (10): pas une bonne idée, à moins d’accepter une part de risque et savoir revenir en arrière (…).
Regarde déjà si systemd 251.3 de Bullseye-backport corrige ton problème, en te posant la question de savoir pourquoi tu ne souhaites pas migrer à Debian 11.
Bonjour,
SID sur Debian 10 c’est le meilleur moyen de finir avec une Frankendebian.
comme le dit @Verner , migre plutôt vers Debian 11 et utilise le dépôt des backports
Bonjour, la version 252 de systemd que je veux tester n’est pas dispo sous le dépôt bullseye-backports (Debian -- Details of package systemd in bullseye-backports)
Non effectivement car c’est la version 252 actuellement en backports. mais vérifie si le bug en question est corrigé dans cette version.
Bonjour,
Serait-ce trop vous demander les références exactes de ce « bug » de systemd qui a l’heur de vous chagriner ?
Comme l’ont fait remarquer d’éminents participants à ce file de discussion, travailler sur un bug d’un composant essentiel du système tout en restant sur une version non à jour dudit système est quelque peu contradictoire 
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« Ce que l’on conçoit bien s’énonce clairement,
Et les mots pour le dire arrivent aisément. »
Boileau De L’Art poétique (Chant I)
On se passerait volontiers de ton ton pour le moins condescendant et de ton commentaire qui n’apporte rien, d’autant plus que je ne « travaille » pas sur le bug en question , mais je souhaite simplement vérifier que mon problème est bien causé par le bug systemd suivant StopWhenUnneeded=true ignored if the unit was spawned as dependency of a device unit · Issue #23410 · systemd/systemd · GitHub dont la correction est implémentée dans la version 252. En effet, la description de ce bug correspond tout à fait au problème que je rencontre.
Cordialement,
@ kiye
Comme au bout de 3 jours, je n’ai pas de réponse complète à mes questions, on va aller droit au but.
Tu n’as pas souhaité répondre à la question sur la non utilisation de Debian 11: c’est ton choix, et ça restera confidentiel.
Comme tu demandes comment il faudrait faire pour essayer systemd qui est un système central, d’une version oldstable (buster) à une version N+2 (sid), la réponse est claire et définitive et sans appel: aucun support pour cette opération ‹ d’essayage ›.
La bonne nouvelle est que tu n’as pas besoin de cette version 252, surtout si ta ‹ problématique › consiste à remplacer un ‹ yes › par un ‹ no › dans un fichier.
Quelle version de systemd utilises-tu actuellement ?
As-tu essayé systemd 247.3-6~bpo10+1 de buster-backports ?
Et accessoirement, quel est ton problème ? (que je suppute lié à udev)
Toujours plus simple de connaître un problème avant de trouver une solution, plutôt que trouver une solution et d’imaginer un problème.
Tout à fait exact, car sinon ce n’est que du problème XY, malheureusement trop fréquent et les hopitaux en sont pleins.
1 J'aime
Si c’est seulement pour tester, pourquoi ne pas faire une autre installation à côté de buster ou sur une autre machine ?
Bonjour,
j’ai bien compris que c’était trop risqué de tester directement une version systemd de sid à partir de buster. J’ai donc suivi vos conseils et j’ai d’abord upgradé mon système vers bullseye. J 'en ai profité pour tester la version de systemd dispo sur bullseye-backports (251) mais comme je m’y attendais, cette version ne corrige pas mon problème.
A partir de là, j’ai installé sans souci la version 252 dispo sur sid et j’ai pu vérifier que cette dernière version corrige bien mon problème
Merci pour vos conseils.
1 J'aime
Comme indiqué plus haut, le problème réside dans le fait que la propriété « StopWhenUneeded » relative aux services s’est mise à ne plus fonctionner après une mise à jour du kernel. Ce problèe a été résolu dans la version 252 de systemd.
Non, ton problème fonctionnel n’est pas ça.
Et pas besoin de systemd 252 pour changer un true en false dans un fichier service (déjà dit).
Je n’ose demander comment tu as installé systemd 252 dans Bullseye, et préfère ne pas savoir.
Note bien ces dépendances de systemd:
Pre-Depends: libblkid1 libc6 libcap2 libgcrypt20 liblz4-1 liblzma5 libmount1 libselinux1 libssl3 libzstd1
Depends: libacl1 libaudit1 libblkid1 libcryptsetup12 libfdisk1 libkmod2 libseccomp2 libsystemd-shared libsystemd0 mount
Recommends: default-dbus-system-bus systemd-timesyncd
Donc tous ces paquets sont de SID, ainsi que leurs propres dépendances, en espérant une compatibilité future avec noyau et D-bus Bullseye.
libc6 de SID dans Bullseye: définitivement plus une Bullseye.
Tu comprendras mieux ton prochain problème de mise à jour de Bullseye/SID, et le sens de mes messages, à savoir d’abord comprendre et analyser un problème avant de supposer « une » solution qui peut être un contournement bancal apparent, mais pas la solution.
Comprendre avant de passer au problème XY 