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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
andre_debian
On Tuesday 21 March 2017 16:46:38 Christophe De Natale wrote:
Sur un Dell Inspiron mini, lors du processus de mise à jour de versi on 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 vo ir ce qu'il se passe en temps réel svp ?
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é
On Tuesday 21 March 2017 16:46:38 Christophe De Natale wrote:
Sur un Dell Inspiron mini, lors du processus de mise à jour de versi on
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 vo ir ce qu'il se
passe en temps réel svp ?
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).
On Tuesday 21 March 2017 16:46:38 Christophe De Natale wrote:
Sur un Dell Inspiron mini, lors du processus de mise à jour de versi on 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 vo ir ce qu'il se passe en temps réel svp ?
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é
Christophe De Natale
Le 21/03/2017 à 17:15, a écrit :
On Tuesday 21 March 2017 16:46:38 Christophe De Natale wrote:
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 ?
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
Le 21/03/2017 à 17:15, andre_debian@numericable.fr a écrit :
On Tuesday 21 March 2017 16:46:38 Christophe De Natale wrote:
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 ?
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.
On Tuesday 21 March 2017 16:46:38 Christophe De Natale wrote:
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 ?
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
Thierry Bugier Pineau
Bonjour 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 :
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
Bonjour
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 :
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 ?
Bonjour 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 :
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
Haricophile
Le Tue, 21 Mar 2017 17:28:25 +0100, Thierry Bugier Pineau a écrit :
J'ai eu plusieurs fois la même expérience en mettant à jou r 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.
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... --
Le Tue, 21 Mar 2017 17:28:25 +0100,
Thierry Bugier Pineau <bugier.t@gmail.com> a écrit :
J'ai eu plusieurs fois la même expérience en mettant à jou r 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.
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...
Le Tue, 21 Mar 2017 17:28:25 +0100, Thierry Bugier Pineau a écrit :
J'ai eu plusieurs fois la même expérience en mettant à jou r 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.
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... --
Christophe De Natale
Le 23/03/2017 à 03:51, Haricophile a écrit :
Le Tue, 21 Mar 2017 17:28:25 +0100, Thierry Bugier Pineau a écrit :
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.
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.
Le 23/03/2017 à 03:51, Haricophile a écrit :
Le Tue, 21 Mar 2017 17:28:25 +0100,
Thierry Bugier Pineau <bugier.t@gmail.com> a écrit :
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.
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.
Le Tue, 21 Mar 2017 17:28:25 +0100, Thierry Bugier Pineau a écrit :
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.
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.
Christophe De Natale
Le 23/03/2017 à 10:11, Christophe De Natale a écrit :
Le 23/03/2017 à 03:51, Haricophile a écrit :
Le Tue, 21 Mar 2017 17:28:25 +0100, Thierry Bugier Pineau a écrit :
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.
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 ?
Le 23/03/2017 à 10:11, Christophe De Natale a écrit :
Le 23/03/2017 à 03:51, Haricophile a écrit :
Le Tue, 21 Mar 2017 17:28:25 +0100,
Thierry Bugier Pineau <bugier.t@gmail.com> a écrit :
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.
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 ?
Le 23/03/2017 à 10:11, Christophe De Natale a écrit :
Le 23/03/2017 à 03:51, Haricophile a écrit :
Le Tue, 21 Mar 2017 17:28:25 +0100, Thierry Bugier Pineau a écrit :
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.
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 ?
Haricophile
Le Tue, 4 Apr 2017 11:07:26 +0200, Christophe De Natale a écrit :
Est-ce que je peux rétablir la situation en ne gardant que "stretch main" dans le sources-list ?
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 --
Le Tue, 4 Apr 2017 11:07:26 +0200,
Christophe De Natale <christophedenatale@orange.fr> a écrit :
Est-ce que je peux rétablir la situation en ne gardant que "stretch
main" dans le sources-list ?
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.
Le Tue, 4 Apr 2017 11:07:26 +0200, Christophe De Natale a écrit :
Est-ce que je peux rétablir la situation en ne gardant que "stretch main" dans le sources-list ?
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 --
Christophe De Natale
Le 05/04/2017 à 03:12, Haricophile a écrit :
Le Tue, 4 Apr 2017 11:07:26 +0200, Christophe De Natale a écrit :
Est-ce que je peux rétablir la situation en ne gardant que "stretch main" dans le sources-list ?
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
Le 05/04/2017 à 03:12, Haricophile a écrit :
Le Tue, 4 Apr 2017 11:07:26 +0200,
Christophe De Natale <christophedenatale@orange.fr> a écrit :
Est-ce que je peux rétablir la situation en ne gardant que "stretch
main" dans le sources-list ?
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
Le Tue, 4 Apr 2017 11:07:26 +0200, Christophe De Natale a écrit :
Est-ce que je peux rétablir la situation en ne gardant que "stretch main" dans le sources-list ?
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
