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

Support Debian
#41

Hmmm, ce que tu dis là me parait très bizarre, en principe lorsque tu fais une mise à jour (on suppose bien entendu que tu passes par le terminal?) tout doit se faire dans le terminal, pas de travail fini au redémarrage, car pour faire une MàJ sous Debian tu dois passer en root… De plus la machine ne peut te supprimer des paquets sans que tu n’en aies eu connaissance dans le retour console de ta commande aptitude safe-upgrade ou apt-get upgrade, avant d’accepter la MàJ…
Si c’est le cas alors je pense que quelque chose n’est pas normal, en tous cas je n’ai jamais rencontré quelque chose de similaire depuis que je suis sous Linux…

Voilà c’est tout à fait ça. Néanmoins, certains paquets ne veulent pas se réinstaller (problème de versions des dépendances), chez moi j’ai le problème avec skype (paquets :i386 manquants), impossible d’installer les linux-headers, …

Commence par voir pourquoi ton système poursuit parfois les MàJ au redémarrage, ça ne me semble pas normal.
Ensuite, comme je l’ai dit, tout doit se faire dans l’écran du terminal, toutes les infos y sont, donc bien lire avant de confirmer la MàJ. :wink:

#42

Merci GOGI pour ta réponse. Le fait que ce comportement n’est pas normal m’a déjà été signalé. Je n’ai moi-même jamais rencontré ce comportement depuis que je suis sous Linux (2009). Mais sur deux machines sous SID, depuis quelques mois, ça arrive assez régulièrement. J’en ai parlé aussi là : cyrille-borne.com/forum/show … hp?tid=499

Je fais toujours, en root, en console :

aptitude update aptitude safe-upgrade

Comme je l’ai toujours fait. C’est vraiment déroutant cette affaire et je ne vois pas bien comment faire. J’ajoute que j’ai vu une fois, après avoir cliqué sur le bouton d’extinction de Gnome, une case à cocher sur la fenêtre de dialogue où on voit “annuler”, “redémarrer”, éteindre", une case à cocher donc, dont l’intitulé était “terminer les mises à jour”. Je suis vraiment surpris de n’avoir rencontrer encore personne connaissant ce comportement du système, et ne sais pas du tout où aller regarder pour “paramétrer” de type de fonctionnement. Où quels logs consulter pour tracer ce comportement.

#43

[quote=“iGor”]Merci GOGI pour ta réponse. Le fait que ce comportement n’est pas normal m’a déjà été signalé. Je n’ai moi-même jamais rencontré ce comportement depuis que je suis sous Linux (2009). Mais sur deux machines sous SID, depuis quelques mois, ça arrive assez régulièrement. J’en ai parlé aussi là : cyrille-borne.com/forum/show … hp?tid=499

Comme je l’ai toujours fait. C’est vraiment déroutant cette affaire et je ne vois pas bien comment faire. J’ajoute que j’ai vu une fois, après avoir cliqué sur le bouton d’extinction de Gnome, une case à cocher sur la fenêtre de dialogue où on voit “annuler”, “redémarrer”, éteindre", une case à cocher donc, dont l’intitulé était “terminer les mises à jour”. Je suis vraiment surpris de n’avoir rencontrer encore personne connaissant ce comportement du système, et ne sais pas du tout où aller regarder pour “paramétrer” de type de fonctionnement. Où quels logs consulter pour tracer ce comportement.[/quote]

C’est sûr que c’est pas normal, j’utilise Linux depuis 2005 environ et j’ai jamais vu ça non plus…
Le plus grave c’est que ça arrive sur deux postes différents, si ce n’était que sur un poste ça pourrait être un bug mais là… Et je n’ai aucune idée d’où ça pourrait venir, ouvres éventuellement un sujet propre à ton problème ici, peut-être que des personnes plus avisées sauront t’éclairer.

#44

Tu as certainement raison. Je vais ouvrir un sujet.

#45

[quote=“GOGI”][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…[/quote]
Bonjour GOGI et merci pour ton intérêt.

Au vu de la séparation franche de mes volumes logiques, il m’a été préférable de passer 1 temps (et quelques) de réinstallation plutôt que dix temps de compréhension et rectification du problème. Au gré de l’apprentissage.

Je ne crois du tout que mes UUID aient étés modifiés par [mono]aptitude safe-upgrade[/mono] d’autant plus que je ne n’utilise pas les UUID pour identifier mes périphériques dans [mono]/etc/fstab[/mono]

Le mode “kernel recovery” n’a plus fonctionné après 2 amorçages.

J’ai même modifié Grub en route pour y mettre un init=/bin/sh

Mais pour quoi faire ? Je n’en savais rien.

Je me méfie de la commande [mono]aptitude safe-upgrade[/mono] comme un animal qui sait avoir perdu du temps.

Mon n40l est réinstallé et reste en stable maintenant.

Le portable n73sm semble digérer Stretch / SID mais je n’y vais que par petites installs ; je n’ose même y pas faire un “upgrade” de sa stretch / sid ; Il saurai planter comme le n40l que je lui remettrai avant tout une Gentoo.

Je n’ai pas bien suivi le fil : l’origine, l’avancement et les conclusions.
Je souhaitai te répondre. Je ne sais pas si tu dis une bêtise.

#46

C’était une idée qui m’est passée par la tête, j’avais eu un problème similaire mais je suis en dual-boot, et des modifications sur une des distrib avait “bousillé” les UUID de la partition racine et du swap de l’autre distrib, donc au démarrage de la 2e distrib eh bien ça a planté… :smiley:
J’avais lu quelque part du temps où j’étais encore sous Ubuntu qu’il valait mieux désigner ses partitions dans fstab par leur UUID plutôt que par leur emplacement, mais je ne sais plus pourquoi…

[quote=“r2mi”]Je me méfie de la commande [mono]aptitude safe-upgrade[/mono] comme un animal qui sait avoir perdu du temps.

Mon n40l est réinstallé et reste en stable maintenant.

Le portable n73sm semble digérer Stretch / SID mais je n’y vais que par petites installs ; je n’ose même y pas faire un “upgrade” de sa stretch / sid ; Il saurai planter comme le n40l que je lui remettrai avant tout une Gentoo.

Je n’ai pas bien suivi le fil : l’origine, l’avancement et les conclusions.
Je souhaitai te répondre. Je ne sais pas si tu dis une bêtise.[/quote]

En tous cas c’est toujours plaisant d’avoir un retour, quel qu’il soit… :wink:
La commande [mono]safe-upgrade[/mono] est la même que [mono]apt-get upgrade[/mono], donc sans danger si tant soit peu que l’on fasse attention à ce que nous retourne la console avant de confirmer.
Safe-upgrade serait même plus sécurisée que d’écrire simplement [mono]aptitude upgrade[/mono], puisqu’elle ne déclencherait les mises à jour uniquement pour les paquets dont elle est sûre que ça n’entrainera pas de suppression d’autres paquets… Enfin jettes un oeil sur le man d’aptitude, comparé à apt-get tu y trouveras des explications plus détaillées…

Quant à [mono]aptitude full-upgrade[/mono], il n’est pas forcément non plus à prendre avec des pincettes, mais il faut ouvrir un peu plus les yeux, et si le retour propose de supprimer des paquets essentiels pendant la MàJ, alors le mieux c’est de laisser en suspens le temps que les bugs soient réglés et mettre à jour tranquillement plus tard…

Concernant le problème de ce fil, pour l’instant j’attends encore de faire un full-upgrade, même si les choses ont l’air d’avancer, puisque maintenant lorsque je tape full-upgrade pour voir les solutions que me propose aptitude, il n’y a plus de suppression de gnome, libreoffice et autres paquets essentiels, néanmoins il y a encore un problème de dépendances qu’aptitude ne sait pas résoudre pour l’instant…
Donc quand ce sera vraiment clean, je ferai la MàJ. Comme ça le système reste “stable”, meme pour une “unstable” :violin: :dance:

#47

le nom des partitions dans /dev est affecté de façon dynamique au démarrage. Rien ne garantie que d’un démarrage à l’autre il ne change pas.
Pour éviter cela, soit tu crées un règle udev, soit tu utilises les UUID.

#48

le nom des partitions dans /dev est affecté de façon dynamique au démarrage. Rien ne garantie que d’un démarrage à l’autre il ne change pas.
Pour éviter cela, soit tu crées un règle udev, soit tu utilises les UUID.[/quote]

Merci piratebab.
Cependant qu’entends-tu par dynamique? Les partitions du disque que l’on a crée ne changent pas dans /dev, j’entends par-là sda1, sda2,…

#49

c’est udev qui affecte les périphériques dans /dev. Rien ne garantie qu’il affectera toujours le même nom au même disque. Ca arrivait fréquement à une époque, puis ça c’est stabilisé. Mais rien ne garantie que lors d’une mise à jour, il change la façon de nommer les disques.
Le risque aussi est de démarrer avec par exemple une stick mémoire USB de connecté. Rien ne garantie que cela ne va pas décaler le nom des disques.
L’UUID, lui est unique. A part un changement physique de disque, il ne changera pas.

#50

[quote=“piratebab”]c’est udev qui affecte les périphériques dans /dev. Rien ne garantie qu’il affectera toujours le même nom au même disque. Ca arrivait fréquement à une époque, puis ça c’est stabilisé. Mais rien ne garantie que lors d’une mise à jour, il change la façon de nommer les disques.
Le risque aussi est de démarrer avec par exemple une stick mémoire USB de connecté. Rien ne garantie que cela ne va pas décaler le nom des disques.
L’UUID, lui est unique. A part un changement physique de disque, il ne changera pas.[/quote]

D’accord, en d’autres termes, du jour au lendemain, suite à une MàJ ou autre, udev peut très bien réattribuer des noms différents aux différentes partition sdxx ou hdxx comme ça sans prévenir en fait…? C’est bon à savoir, merci. :wink:

#51

et quand ça t’arrive , et que tu as deux disques ou plus, ça ne boote plus! Et tu es dans la m…

#52

hahahah oui ça je connais, j’ai déjà dans le passé réussi à flinguer ma table de partitions sans udev ni personne d’ailleurs… Plus rien ne bootait, ni Windows, ni Linux… :smiley:
Il me semble que j’avais tenté de redimensionner une des partitions qui se trouvait en amont (vers la gauche dans l’ordre d’apparition) à “chaud”… Bon c’est pas tout à fait la même chose, mais au redémarrage ça a pas loupé :119 :mrgreen: Plus de MBR plus rien… :smiley:
Impossible de passer par Windows Recovery, ni Linux pour réparer, j’ai du récuperer un logiciel qui répare la MBR d’abord puis sauver ce qui pouvait etre sauvé avant de reinstaller tout :smiley: :smiley: :smiley:

Mais ça, c’était avant… :violin: :mrgreen: Depuis j’ai appris… à ne plus le faire. :mrgreen:

#53

Bon, je ne vais pas ouvrir un nouveau sujet car je pense que le problème suivant est intimement lié à cette mise à jour en suspens…

Alors voilà la bête noire : MEGA BUG de libreoffice :smiley:
Je m’explique, depuis que j’ai fait la réinstallation de Debian, je n’ai pas touché à libreoffice. Hier soir, j’avais besoin de Calc pour éditer un document et là surprise : Calc est totalement bug-é!!!
Plus aucun calcul mathématique avec les simples opérandes (+, -, *, /), seules les fonctions “fonctionnent”. En réalité lorsque par exemple :

  • je remplis la cellule A1 avec un chiffre
  • la cellule A2 avec un autre chiffre
  • et que j’écris dans la cellule A3 “=A1+A2”

La cellule A3 me renvoie un résultat booléen de type [mono]VRAI[/mono] ou [mono]FAUX[/mono]. Si je tente de supprimer le formatage de la cellule evidemment il renvoie les valeurs 1 ou 0… Mais mis à part ça, impossible d’effectuer un seul calcul simple, à moins de remplacer les signes simples des opérandes habituels par leurs formules respectives… Casse-pied pour un tableur quand même…

Alors sachant qu’à cause de cette mise à jour qui fout un bordel pas possible en ce moment, et qui entre autres met en attente la mise à jour également de plusieurs paquets dont la suite libreoffice, est ce que ça pourrait être dû à ça?

Est ce que quelqun rencontre aussi ce problème?

#54

Depuis le temps … c’est quoi pour toi une Debian Sid ?

#55

Depuis le temps? je comprends pas :smiley: tu fais référence à mon msg ou à Sid?

Bah Debian “Sid” = Unstable

#56

Et bien comment dire … je pensais que tu étais au courant depuis le temps une Debian Sid ça bug c’est fait pour : :008

#57

ahahahha oui merci ça je suis au courant :wink:

Mais de là à avoir un tel bug sur libreoffice c’est quand même balaise :smiley: Sans déconner, je suis persuadé que c’est ce passage à gcc-5 qui fout tout le patacaisse, il est maintenant fort probable que certaines librairies soient passées en safe-upgrade et que j’ai fait la MàJ tandis que d’autres paquets sont encore bloqués sous full-upgrade (dont libreoffice lui même) et résultat appli inutilisable :smiley: :033 :033 :033

#58

Alors je me réponds à moi-même en ce qui concerne libreoffice calc, l’intelligence de ceux qui s’occupent des dépôts a voulu qu’ils placent le paquet de langue française pour calc dans les dépôts unstable à la version supérieure en safe-upgrade, alors que libreoffice lui attend toujours en full-upgrade que les dépendances bug-ées soient résolues…

Couplé à mon intelligence de n’avoir pas bien ouvert les yeux lors d’un récent safe-upgrade j’ai fait passer le fameux paquet [mono]libreoffice-l10n-fr[/mono] à la version 5.0 alors que libreoffice calc en est encore à la version précédente, soit 4.4-5.

Résultat : le bug ci-dessus :033
Donc par rétrogradation de la version du paquet de langue je retrouve un fonctionnement normal… Bref pas mal de bordel en ce moment… :mrgreen:

EDIT : la solution m’est venue de là pour ceux que ça pourrait intéresser https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794024

#59

Et pourtant… “Unstable” n’est pas sensé signifier “instable en terme de fonctionnement”, mais instable au niveau de la version des paquets qui composent le système, qui évoluent sans cesse et à fréquence élevée. Donc statistiquement on a plus de chance de rencontrer des bugs sur une SID, certes, mais ça n’est pas sensé être sa caractéristique principale. :think:

#60

Et là c’est un bug majeur je trouve perso, car dans les mises à jour qui sont bloquées à cause de certains paquets qui cassent d’autres, il y a peut-être des failles de sécurité qui sont aussi en attente…
Bref il y en a peut-être pour un moment là je pense…