=c3=a9cran noir pendant upgrade jessie > stretch
Le
Christophe De Natale
Bonjour à vous,
Sur un Dell Inspiron mini, lors du processus de mise à jour de version
de jessie vers stretch, l'écran est devenu noir et je ne peux plus
suivre l'évolution du process.
Une action sur le pavé tactile ou une touche du clavier laisse
apparaître le temps d'un instant le fond d'écran
J'ai accès à la console, existe-t-il une possibilité de voir ce qu'il se
passe en temps réel svp ?
Sincèrement,
Christophe De Natale
Sur un Dell Inspiron mini, lors du processus de mise à jour de version
de jessie vers stretch, l'écran est devenu noir et je ne peux plus
suivre l'évolution du process.
Une action sur le pavé tactile ou une touche du clavier laisse
apparaître le temps d'un instant le fond d'écran
J'ai accès à la console, existe-t-il une possibilité de voir ce qu'il se
passe en temps réel svp ?
Sincèrement,
Christophe De Natale
Le module vidéo de Jessie n'a pas suivi pendant l'upgrade vers Stretch ?
Refaire l'upgrade en mode boot recovery (sans serveur X).
André
Attends, j'ai mieux sûrement :D
Même avec mes lunettes je n'ai pas vu que j'avais pris le cd i386 hier
soir...
C'est un Celeron® M Processor ULV 743 donc amd64
Bizarre, je n'ai pas eu d'avertissement sur la non-correspondance de
l'architecture.
Merci quand même et désolé pour le bruit.
Christophe De Natale
J'ai eu plusieurs fois la même expérience en mettant à jour mon
système, ça m'arrive en principe quand j'ai beaucoup de paquets à
mettre à jour (notamment ceux touchant à Xorg). J'en ai conclu qu'il
vaut mieux faire de telles mises à jour en mode console.
Passer de Jessie vers Stretch en mode graphique me parait risqué
justement parce qu'on passe obligatoirement par la mise à jour de
l'environnement graphique, avec un grand bond en avant.
La première chose que je ferais, serait d'avoir un ISO ou une clé USB
de secours pour booter dessus en mode récupération. Ensuite avec une
console, faire
apt-get install -f
Le prix étant de couper le système de manière un peu sauvage.
Si ssh fonctinne encore, il p a peut être moyen d'arrêter le système de
manière plus douce, voire reprendre la mise à jour, toujours avec apt-
get install -f
Le mardi 21 mars 2017 à 16:46 +0100, Christophe De Natale a écrit :
Thierry Bugier Pineau
J'approuve totalement. De même éviter au maximum le dist-upgrade en
graphique avec un pilote graphique propriétaire activé, surtout
compilé/installé hors distrib sans le gestionnaire de paquet...
--
Bonjour,
En installant en amd64, cela s'est bien passé (en suivant votre conseil
pour la console).
Par contre, je n'ai pas eu le temps d'aller plus loin mais en modifiant
les sources afin d'installer "stretch", le système entame la procédure
et ne va pas au bout (le noyau reste en 3.16 et 320 mises à jour ne sont
pas appliquées).
Je gratte plus loin dès que j'ai 5 min.
Bonjour,
Le problème est résolu en installant "linux-image-amd64" depuis les
backports puis mise à jour du sources-list pour Stretch.
Par contre, comme j'ai oublié de supprimer "contrib et non-free", je me
retrouve avec 350 paquets non mis à jour.
Est-ce que je peux rétablir la situation en ne gardant que "stretch
main" dans le sources-list ?
Christophe De Natale
Le rétropédalage est toujours délicat, il faut voir ce qui a été fait
ou pas. Supprime ce qui n'est pas nécessaire et ait une politique
cohérente : Plus tu utilise des solutions "exotiques" et plus tes
problèmes vont devenir compliqués.
Si c'est juste pour le kernel, tu peux effectivement garder "strech
main" et utiliser le pinning pour ne pas installer les paquets sauf
celui du kernel que tu veux. Tu peux aussi l'installer manuellement ou
le compiler.
https://debian-facile.org/doc:systeme:apt:pinning
--
Bonjour et merci de la réponse,
En fait, c'est le paquet "rdnssd" qui était la cause d'un problème de
dépendances.
Sa désinstallation permet à la mise à jour d'aboutir.
Le bug est décrit ici :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bugt0998