Debian Sid : problème majeur système après MàJ d'aujourd'hui

Support Debian
#21

[quote=“manas”]Bonjour,
Utilisateur de Sid depuis peu je lis ce fil et je m’interroge:
J’utilise habituellement apt update && apt upgrade pour faire les M.A J .
Est il préférable d’utiliser " aptitude-safe upgrade " ?
Merci.[/quote]

Salut,

Préférable je ne sais pas, mais vu ce qui vient de m’arriver perso j’opterais pour aptitude à l’avenir plutôt qu’apt-get…
Aptitude est plus verbeux à mon sens, après des avis plus éclairés seraient bienvenus en effet…

D’ailleurs pour ceux qui utilisent et connaissent les deux, je serai curieux de savoir si on peut utiliser les deux ou bien c’est déconseillé? Certains disent qu’on peut maintenant, d’autres le déconseillent…

#22

J’utilise apt-get, par habitude, mais parfois sur des cas un peu compliqué, je passe par aptitude. Des fois ça décoince, des fois pas …
Jamais vu du problème à faire comme ça, même si ce n’est pas recommandé.

#23

[quote=“piratebab”]J’utilise apt-get, par habitude, mais parfois sur des cas un peu compliqué, je passe par aptitude. Des fois ça décoince, des fois pas …
Jamais vu du problème à faire comme ça, même si ce n’est pas recommandé.[/quote]

Je me fais la main en ce moment avec aptitude, avant de faire une réinstall complète qui était prévue depuis quelque temps, donc j’ai pas de recul réel.
Néanmoins j’ai lu par-ci par-là dans différents sujets qui traitent la question, que certains déconseillent d’utiliser les deux, à cause du traitement des dépendances, où par exemple un paquet installé avec aptitude pourrait être supprimé par apt-get par la suite (ou bien certaines des ses dépendances) lors d’une mise à jour car les deux ne traitent pas les dépendances de la même manière, et/ou vis-versa?

#24

Tiens, je fais plutôt l’inverse. aptitude est assez fort pour gérer les problèmes de dépendances, mais il est parfois long à trouver une solution. Et quand le temps de calcul est trop long, aptitude s’arrête tout simplement. Dans ces cas, j’utilise apt-get pour mettre à jour les paquets qui peuvent l’être. apt-get ne cherche pas de solutions à base de “conserver”, “mettre à jour”, “supprimer”, “revenir à une ancienne version”, “installer un nouveau paquet”. Il se content de mettre à jour ce qui peut être mis à jour, de supprimer les dépendances qui ne sont plus nécessaires, et d’installer les nouvelles dépendances. Si un paquet coince, il le conserve en l’état.

Sinon, j’utilise les deux depuis plus de 3 ans en Sid et n’ai jamais rencontré de problème du à leur cohabitation.

GOGI : si l’un supprime les dépendances installées par l’autre, peut-être que ce ne sont pas de réelles dépendances, mais de simples recommandations. Il est possible d’avoir quelques cafouillages (mais rien de grave) si les deux outils sont configurés différemment. Si apt-get installe les recommandations, et aptitude seulement les dépendances, par exemple. Mais ça reste anecdotique et pas grave du tout.

#25

J’aurai dis la même chose! :wink:

Je ne sais plus exactement le contexte, j’ai été très vague dans mon explication, à force de lire plein de choses à droite à gauche on retient pas tout :smiley: mais j’ai retenu qu’il fallait se méfier car dans certains cas de figure il y a possibilité de se retrouver dans la mouise :smiley:
Celà dit j’ai pas souvenir qu’apt-get installe les recommandations? il me semble qu’il ne fait que les suggérer non?

#26

Merci pour vos réponses. Je vais me faire la main dans le but d’apprendre.

#27

[quote=“GOGI”]D’ailleurs pour ceux qui utilisent et connaissent les deux, je serai curieux de savoir si on peut utiliser les deux [strike]ou bien[/strike] c’est déconseillé? Certains disent qu’on peut maintenant, d’autres le déconseillent…
[/quote]
Ce débat n’a plus lieu d’être.

#28

[quote=“BelZéButh”][quote=“GOGI”]D’ailleurs pour ceux qui utilisent et connaissent les deux, je serai curieux de savoir si on peut utiliser les deux [strike]ou bien[/strike] c’est déconseillé? Certains disent qu’on peut maintenant, d’autres le déconseillent…
[/quote]
Ce débat n’a plus lieu d’être.[/quote]

c’est à dire Belzébuth? :think:

#29

Peut-être. Je ne suis pas vraiment un pro de apt-get. Mais on peut configurer aptitude pour installer automatiquement les recommandations, et donc se retrouver dans le cas inverse que celui que je présentais.

#30

Pas chez moi.

[20:51:33]:~$ cat /etc/apt/apt.conf (...) APT::Install-Suggests "false"; APT::Install-Recommends "false"; Aptitude::Recommends-Important "false"; Aptitude::Suggests-Important "false"; (...)
PS :[mono]$ man apt.conf[/mono]

#31

Si BelZéButh, tu peux ^^
Tu ne l’as pas fait (comme la majorité des gens, je pense), mais tu peux le faire.

#32

[quote=“GOGI”][quote=“BelZéButh”][quote=“GOGI”]D’ailleurs pour ceux qui utilisent et connaissent les deux, je serai curieux de savoir si on peut utiliser les deux [strike]ou bien[/strike] c’est déconseillé? Certains disent qu’on peut maintenant, d’autres le déconseillent…
[/quote]
Ce débat n’a plus lieu d’être.[/quote]

c’est à dire Belzébuth? :think:[/quote]

Comme le dit Belzébuth?, le débat n’a pas lieu d’être, les deux ont toujours pu s’utiliser en même temps en gardant à l’esprit que les paquet ‘marked’ par l’un ne seront pas pris en compte par l’autre et encore que je ne sais pas si c’est tjs d’actualité.

[quote=“Dunatotatos”]Si BelZéButh, tu peux ^^
Tu ne l’as pas fait (comme la majorité des gens, je pense), mais tu peux le faire.[/quote]

Il n’a pas dit que c’était impossible mais seulement que chez lui il n’était pas configuré pour :smiley:

#33

Bonjour,

J’ai effectué il y a deux jours un :

Beaucoup de paquets ont été supprimés. Et tout mon système est planté ; comme indication :

l’affichage très tôt de :
lvmetad is not active yet, using direct activation during sysinit
(compte en secondes / estimation de fin de compte) a start job is running for dev-mapper-vg0\x2dLV.device (LV étant chacun de mes volumes logiques)
ça prend une minute trente en tout environ.

Le dernier texte que j’ai à l’écran à la reprise ne montre que des STOPPED ou des CLOSED suivis de :
Starting LSB : Prepare console…
Started LSB : Prepare console.
Starting LSB : Set console font and keymap…
Starting LSB : Set console font and keymap.
rub
Et puis plus rien même en attendant longtemps.

Le mode de maintenance avec le noyau recovery échoue même maintenant :

le (compte en secondes / estimation de fin de compte) a start job is running for dev-mapper-vg0\x2dLV.device (LV étant chacun de mes volumes logiques)
(ça prend une minute trente en tout environ) est effectué également.

[DEPEND] Dependency failed for emergency shell
[DEPEND] Dependency failed for emergency Mode

Je pense que mon problème tourne autour de ce dev-mapper et de Grub
Et que mes volumes logiques ne sont plus reconnus au démarrage.

une photo des paramètres d’amorçage Grub (recovery mode)
https://drive.google.com/file/d/0B2motSLuTTTTeFFOOXI4eGJ5S2M/view?usp=sharing

Je ne sais pas trop quoi faire, je sais aller en recovery mode depuis le CD minimal

#34

Bonjour,
J’ai une Jessie en roue de secours au cas où…ce qui ne manquera pas d’arriver;
Bon courage !

#35

[quote=“r2mi”]Bonjour,

J’ai effectué il y a deux jours un :

Beaucoup de paquets ont été supprimés. Et tout mon système est planté ; comme indication :

l’affichage très tôt de :
lvmetad is not active yet, using direct activation during sysinit
(compte en secondes / estimation de fin de compte) a start job is running for dev-mapper-vg0\x2dLV.device (LV étant chacun de mes volumes logiques)
ça prend une minute trente en tout environ.

Le dernier texte que j’ai à l’écran à la reprise ne montre que des STOPPED ou des CLOSED suivis de :
Starting LSB : Prepare console…
Started LSB : Prepare console.
Starting LSB : Set console font and keymap…
Starting LSB : Set console font and keymap.
rub
Et puis plus rien même en attendant longtemps.

Le mode de maintenance avec le noyau recovery échoue même maintenant :

le (compte en secondes / estimation de fin de compte) a start job is running for dev-mapper-vg0\x2dLV.device (LV étant chacun de mes volumes logiques)
(ça prend une minute trente en tout environ) est effectué également.

[DEPEND] Dependency failed for emergency shell
[DEPEND] Dependency failed for emergency Mode

Je pense que mon problème tourne autour de ce dev-mapper et de Grub
Et que mes volumes logiques ne sont plus reconnus au démarrage.

une photo des paramètres d’amorçage Grub (recovery mode)
https://drive.google.com/file/d/0B2motSLuTTTTeFFOOXI4eGJ5S2M/view?usp=sharing

Je ne sais pas trop quoi faire, je sais aller en recovery mode depuis le CD minimal[/quote]

Je dis peut-être une bêtise, mais est-ce que ce genre de souci ne correspond pas à un fichier fstab corrompu, comme lorsqu’on modifie des partition ou bien on réinstalle un OS sur une partition, et cette opération modifie les UUID des autres partitions…

Si tu peux passer en mode console de secours, essaie de faire un fdisk -l pour relever les UUID de tes différentes partitions, et vérifies dans le fichier fstab si c’est bon…

#36

Ah ok comme ça c’est plus clair, merci du complément :wink:

#37

[quote=“GOGI”]Bon, je viens vous tenir un peu au courant… :smiley:

J’ai réussi à récuperer mon installation Sid, grâce à l’idée de Martin de faire régresser le paquet libstdc++6 à la version du dépôt Testing, ce qui m’a permis de réinstaller gdm3 et retrouver mon bureau préféré :stuck_out_tongue:
En passant par apt-cache policy, puis par aptitude pour faire régresser à la version antérieure ce fameux paquet, aptitude m’a proposé de faire également régresser un nombre d’autres paquets (dépendances oblige), ce que j’ai fait…
Puis réinstallé gdm3 et c’est reparti comme en 14…

Néanmoins le problème vient clairement du paquet libstdc++6, en fait sa mise à jour casse d’autres paquets et provoque la désinstallation de gdm3 et environ 40 autres paquets…

Maintenant il me reste à voir s’il n’y a rien d’autre de cassé, et je laisserai ce post ouvert tant que cette histoire avec ce fameux paquet ne sera pas réglée…

Merci à Martin et Belzebuth pour votre participation, et si vous avez des choses à ajouter par rapport à ce que je viens de dire je suis preneur :wink:[/quote]

Hello, je fais face au même problème que toi tu as eu: libstdc++6 qui m’a cassé mon gnome, gdm et libreoffice. J’ai essayé de réinstaller une version antérieure mais je n’ai pas réussi. Qu’as-tu dans /etc/apt/sources.list? Et comment as-tu procédé pour réinstaller une version antérieure?

Voici mon /etc/apt/sources.list:
http://pastebin.com/ctRgzxWN

Sinon si je fais un lsb_release -a, j’obtiens:
Distributor ID: Debian
Description: Debian GNU/Linux unstable (sid)
Release: unstable
Codename: sid

Voilà, si quelqu’un peut me dépanner ce serait cool :038 :038 :038

Merci d’avance

#38

[quote=“prosouth”]Hello, je fais face au même problème que toi tu as eu: libstdc++6 qui m’a cassé mon gnome, gdm et libreoffice. J’ai essayé de réinstaller une version antérieure mais je n’ai pas réussi. Qu’as-tu dans /etc/apt/sources.list?

Voici mon /etc/apt/sources.list:
http://pastebin.com/ctRgzxWN

Sinon si je fais un lsb_release -a, j’obtiens:
Distributor ID: Debian
Description: Debian GNU/Linux unstable (sid)
Release: unstable
Codename: sid

Voilà, si quelqu’un peut me dépanner ce serait cool :038 :038 :038[/quote]

Quand tu essaies de réinstaller une version antérieure, le retour console te dit que les dépendances ne sont pas satisfaites car un ou plusieurs paquets plus récents ont été installés…

Voici ma sources.list : pastebin.com/9uQFCJbm
Tu peux t’en servir pour adapter la tienne, mais gardes en tête que ce n’est pas LA sources.list!
Par contre si tu veux être sous Debian Sid, quelle que soit ta sources.list, commentes tout ce qui a attrait aux dépôts STABLE (ou Jessie en l’occurence, pour voir la différence entre Stable et “Jessie” consulte le wiki) et gardes uniquement les dépôts Testing/Stretch et Sid/Unstable…
Et vires le dépôt Experimental (enfin c’est mon opinion perso mais à moins que tu ne sois développeur, c’est trop risqué).

Pour faire régresser libstdc++6 à une version antérieure et pouvoir réinstaller gnome, gdm3 et libreoffice (et encore quelques paquets qui ont été désinstallés avec, pour la liste complète consultes tes fichiers log dans /var), il faut que tu forces la régression de celui-ci :

su - aptitude install libstdc++6=5.1.1-14

La version 5.1.1-14 est celle qui est dans le dépôt testing, la version 5.2.1-14 est celle qui est dans le dépôt Sid et qui pose problème.
La manip ci-dessus va forcer la régression du paquet, alors de mémoire il me semble que le retour console va te proposer de faire régresser d’abord un autre paquet duquel dépend libstdc++6, évidemment tu acceptes, et ensuite la régression va se faire…
Après ça tu peux réinstaller tranquillement gdm3, gnome et autres…

#39

Bonjour,

Ça fait un moment que je cherche des informations similaires… J’ai deux postes sous Sid, et il m’arrive assez souvent des problèmes similaires, et ce matin c’était le problème indiqué dans ce fil. Mais je vais faire une description plus “générale” du fonctionnement que je crois avoir constaté.

Tout commence avec une mise à jour. Depuis quelques temps, échaudé par ce genre de problème, je ne fais plus que des aptitude safe-upgrade et j’observe bien les retours de commande. Donc une mise à jour. Je n’ai pas de message me prévenant de quoi que ce soit, hormis que des paquets vont être mis à jour, d’autre laissé en l’état, et c’est tout.

Au bout d’un moment, j’éteinds mon PC. Hé, oui, ça m’arrive… Et c’est là que ça devient intéressant. Sans prévenir, le système redémarre, reste en mode console, et finit la mise à jour, supprime et installe des paquets et s’éteint “normalement”. J’ai cru comprendre que c’était un comportement normal depuis systemd, mais je ne suis pas plus que ça sûr de moi et je n’ai rien contre systemd, a priori. Et c’est là que le système peut se mettre à supprimer un nombre assez étonnant de paquets, mais quel que soit le nombre, dans le tas il y a toujours gnome-shell, gnome-core, gnome-session, au moins.

Du coup, au redémarrage, forcément, on se retrouve en tt1. Après quelques tâtonnement, j’ai fini par trouver la liste des paquets supprimés grâce à un cat /var/log/dpkg.log | grep remove, dont on peut éventuellement injecter la sortie dans un fichier texte. À partir de là, j’essaie de réinstaller les paquets manquants, avec des problèmes de dépendances et de conflits, mais en général j’arrive au moins à réinstaller gnome-shell et gnome-session, non sans devoir préciser que je veux bien la version du dépôt Sid.

Mon sources.list :

[code]# source.lists

inspiré de https://www.isalo.org/wiki.debian-fr/L'etiquetage_de_paquets_via_le_fichier_/etc/apt/preferences

stable

deb http://ftp.ch.debian.org/debian/ jessie main contrib non-free
#deb-src http://ftp.ch.debian.org/debian/ jessie main contrib non-free

stable security

deb http://security.debian.org/ jessie/updates main contrib non-free
#deb-src http://security.debian.org/ jessie/updates main contrib non-free

jessie-updates, previously known as ‘volatile’

deb http://ftp.ch.debian.org/debian/ jessie-updates main contrib non-free
deb-src http://ftp.ch.debian.org/debian/ jessie-updates main contrib non-free

jessie-backports, previously on backports.debian.org

deb http://ftp.ch.debian.org/debian/ jessie-backports main contrib non-free
deb-src http://ftp.ch.debian.org/debian/ jessie-backports main contrib non-free

testing

deb http://ftp.ch.debian.org/debian/ testing main non-free contrib
#deb-src http://ftp.ch.debian.org/debian/ testing main non-free contrib

sid

deb http://ftp.ch.debian.org/debian/ sid main contrib non-free
#deb-src http://ftp.ch.debian.org/debian/ sid main contrib non-free[/code]

Ce que j’aimerais comprendre, c’est comment il serait possible de “prévenir” le truc, et de connaître à l’avance ce genre de problème de dépendances, afin d’attendre un moment avant de faire la mise à jour. Parce que à chaque fois que ça m’est arrivé, à chaque fois je n’ai rien vu venir. Je ne dis pas que l’on ne peut pas voir, mais que je n’ai rien vu venir.

#40

A mon niveau de compréhension, je partage le même soucis !