Y a-t-il un moyen d'annuler la mise à niveau la plus récente?

46

Cela m’est arrivé à plusieurs reprises au cours des 5 dernières années: une mise à niveau a brisé mon système. Chaque fois que je me retrouve avec cette situation, je dois réinstaller l’ensemble du système, ce qui est vraiment gênant.

Est-il possible de restaurer la mise à niveau la plus récente pour pouvoir disposer d'un système fonctionnel sans réinstaller? Si non, quelle est la meilleure façon de suggérer cela comme une idée prioritaire?

J'ai lu que cette idée était décrite dans brainstorm.ubuntu.com, mais elle a l'air morte ... et les forums sont pleins d'exemples de mises à jour qui brisent les choses, c'est pourquoi je pense qu'il faut faire quelque chose à ce sujet. Merci!

    
posée Marcelo Ruiz 13.04.2011 - 17:45
la source

6 réponses

11

Dans les synaptics, vous pouvez au moins contrôler les dernières mises à jour: File-menu, history.

(si synaptic est démarrable, avec le système cassé). Donc, avec une commande apt -...-, pour annuler leur mise à jour, cela ne devrait pas être trop difficile.

Je suppose qu'il y a aussi une commande history pour la ligne de commande.

Vous devez peut-être supprimer le package complet et installer une version spécifique. Bien sûr, il est possible d'installer une version spécifique, mais je n'ai jamais eu besoin de le faire.

update: Recherche comment faire avec apt:

Trouvez les paquets installés dans les 3x24h derniers:

find /var/lib/dpkg/info/ -name \*.list -mtime -3 | sed 's#.list$##;s#.*/##' 

Avec la stratégie apt-cache, vous voyez les versions disponibles d'un programme:

sudo apt-cache policy PROGRAM:
 *** 3.6.7+build3+nobinonly-0ubuntu0.10.04.1 0
        500 http://de.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
        500 http://security.ubuntu.com/ubuntu/ lucid-security/main Packages
        100 /var/lib/dpkg/status
     3.6.3+nobinonly-0ubuntu4 0

ici 3.6.7 et 3.6.3. Maintenant, vous savez quelle version antérieure peut être installée (souvent pas le prédécesseur immédiat):

sudo apt-get install PROGRAM=3.6.3

Ensuite, vous devez faire un apt-pinning, pour empêcher les futures mises à jour:

Créez un nouveau fichier dans /etc/apt/preferences.d/ (si & gt; = 10.4) nommé d'après votre programme,

Package: program
Pin: version 3.6.3*
Pin-Priority: 1000
    
réponse donnée user unknown 13.04.2011 - 19:08
la source
6

La plupart du temps, si votre système est endommagé, il s’agit d’un problème du noyau .

Amorcez simplement un noyau plus ancien et réinstallez les paquets les plus récents (en particulier les paquets du noyau) qui ne se sont probablement pas mis à jour correctement. Quelques notes:

/var/log/dpkg.log

est votre ami pour vérifier quelle est la liste des paquets récemment mis à jour / installés

sudo apt-get -f install

peut réparer la plupart du temps des paquets semi-installés

    
réponse donnée Giordano Battilana 22.09.2012 - 11:49
la source
5

La plupart du temps, vous pouvez consulter /var/log/apt/history.log pour les modifications effectuées par apt / synaptic. C'est juste un peu médico-légale et beaucoup de couper / coller à faire.

Revenez à la date à laquelle votre système fonctionnait toujours correctement.

Commencez par prendre tous les paquets installés depuis lors et regroupez-les dans un script de désinstallation. Lorsque le script est terminé, recommencez à rajouter tous les packages supprimés.

Un exemple:
fichier journal:

Start-Date: 2014-05-28  21:28:11
Commandline: synaptic
Install: libfglrx-amdxvba1:amd64 (13.12-3kali1, automatic), libgl1-fglrx-glx:amd64 (13.12-3kali1), glx-alternative-fglrx:amd64 (0.4.1kali1, automatic), libfglrx:amd64 (13.12-3kali1, au$
Remove: fglrx-glx-ia32:amd64 (12-6+point-3)
End-Date: 2014-05-28  21:28:27

vous pouvez voir,

libfglrx-amdxvba1:amd64 libgl1-fglrx-glx:amd64 glx-alternative-fglrx:amd64 & libfglrx:amd64 

installé par Synaptic. comme libfglrx:amd64 a été supprimé par Synaptic.

Nous sommes allés dans l'ordre inverse, donc nous retirons d'abord les paquets nouvellement installés et nous rajoutons les paquets supprimés.

Une commande de travail pour ce cas pourrait ressembler à:

sudo apt-get remove -y libfglrx-amdxvba1:amd64 libgl1-fglrx-glx:amd64 glx-alternative-fglrx:amd64 libfglrx:amd64 && sudo apt-get install -y libfglrx:amd64

Peut-être que ce ne serait pas la meilleure idée d'aller sans le commutateur -y - pour avoir plus de contrôle sur le processus (pour éviter les dépendances brisées). La plupart d'entre vous ne se casseraient pas le doigt en faisant quelques vérifications "y"

Dans la plupart des cas, une restauration est possible de cette façon, mais si des dépendances sont déjà rompues - vous pouvez rencontrer un problème encore plus important.

    
réponse donnée Matt 29.05.2014 - 11:46
la source
3

Malheureusement, il n'y a aucun moyen de le faire pour le moment. Le snapshot / rollback au niveau du système de fichiers est l’une des fonctionnalités des btrfs à venir, mais il n’a pas encore été possible de le rendre suffisamment complet et stable pour être utilisé comme système de fichiers par défaut.

    
réponse donnée psusi 13.04.2011 - 20:33
la source
3

Lorsque vous effectuez une mise à niveau majeure, je clone le disque en utilisant Clonezilla . Gravez-le sur un CD, ayez un disque dur externe (externe) disponible et suivez les instructions sur le LiveCD Clonezilla. Choisissez le mode partition-image , cela utilise le moins d'espace.

Si vous pensez que vous avez cassé votre système (ou souhaitez annuler les modifications), démarrez simplement le LiveCD Clonezilla, sélectionnez l’image sur votre disque dur (externe) et restaurez-le. Comme ces images sont une copie littérale de chaque bit de votre disque, cela peut prendre quelques heures en fonction de la vitesse de votre disque et de la vitesse de connexion (connexion entre les données, généralement un disque dur USB externe et l'ordinateur).

Au fait, cela s'appelle une méthode de sauvegarde.

    
réponse donnée Lekensteyn 13.04.2011 - 23:02
la source
2

Vous pouvez installer une ancienne version d’un package donné (downgrade) avec apt ou dpkg facilement . Le problème est de trouver une ancienne version du package, car celles-ci disparaissent souvent du pool et des miroirs lorsque les mises à jour sont intégrées.

Si vous installez le package à partir d’un CD d’installation ou d’un miroir obsolète ou d’un cache, vous devrez également le conserver sur l’ancienne version pour qu’elle ne soit pas mise à niveau tant que vous ne l’autorisez pas. Ce qui signifie que vous devez surveiller les mises à jour et les tester jusqu'à ce que votre problème soit résolu. Ceci est bien sûr un problème car en attendant (peut-être pour toujours), il vous restera le paquet non fixé, éventuellement non sécurisé. Cela signifie que chaque utilisateur avec une sorte de problème de système sera laissé dans un état aléatoire jusqu'à ce qu'il puisse le résoudre.

Tous les logiciels ne sont pas non plus compatibles avec l’avance, de sorte qu’une version plus ancienne de quelque chose pourrait bien ne pas se comporter correctement avec des fichiers de configuration ou de données plus récents. Évidemment, cela est impossible à résoudre, à moins que vous ne ramassiez également toutes les données utilisateur à un état antérieur à la mise à niveau.

Ce serait génial s'il y avait un moyen de le faire, mais c'est extrêmement problématique. Quiconque pense qu'il existe une solution cohérente doit rédiger une proposition et inviter des commentaires ou, mieux encore, apporter une solution de preuve de concept (code, script, document). Traîner et pleurnicher n'est pas constructif.

Étant donné qu’il n’existe pas de solution technique propre, la plupart des logiciels sont développés (et intégrés) avec la mentalité «la seule solution est d’être en avant». Essayer de gérer des versions obsolètes est une perte de temps pour tout le monde. Les problèmes détectés sont résolus dans les nouvelles versions dès que possible. En tant que solution mineure, j'aimerais voir une archive des versions précédentes du package conservée quelque part pour une solution de contournement temporaire occasionnelle.

Pendant ce temps, vous pouvez signaler des bogues et ne pas s’attendre à ce qu’un logiciel de pointe ne tombe en panne. Un correctif, une fois trouvé, devrait figurer dans la prochaine mise à jour. Les devs sont des humains (principalement), et donc faillibles. Les ordinateurs sont rapides et pleins de variété et de détails insensés. Les systèmes à gestion défensive utilisant des composants bien pris en charge et une distribution logicielle intégrée stable peuvent être très stables sans devenir insécurisés ou ne pas pouvoir être mis à niveau malgré cela.

    
réponse donnée XTL 12.11.2012 - 12:25
la source

Lire d'autres questions sur les étiquettes