lxtrem a écrit 26 commentaires

Super, je vais continuer de chercher avec aptitude, je vous tiens au courant !

Oui, après un update & upgrade.
Je ne me souviens plus des paquets mis à jour mais après ca, l'installation de libdrm2:i386 via backports ca bien fonctionné.

J'ai compris comment fonctionnait le TUI de aptitude, ce qui simplifie grandement les choses !
Voici un screenshot pour libgl1-mesa-dri:i386:

Certaines libs sont disponibles en backports et d'autres non, ca pourrait venir d'ici ?

C'est assez similaire pour libgl1-mesa-glx:i386, sauf que une des lib est dispo en backports et pas en stable.

Je précise que ces images sont prises sur la version backports de ces paquets.
J'ai beau tenter et chercher partout, backports ou pas, à chaque fois un conflit 32/64 bits…

Même avec apt-get, il me dit que les paquets sont à jour.
libdrm2 64bits était bien installée, c'était la version 32 bits qui coincait, mais pour une raison inconnue, après une mise à jour, un simple sudo apt install -t stretch-backports libdrm2:i386 a eu raison de lui.
Malgré ca, le paquet Steam bloque toujours au même endroit, et si je remonte aux paquets sources qui posent problème, il y en a beaucoup.
Voici un schéma de la situation:

J'ai pas tout essayé en 64 bits mais a chaque essai, la lib était bien installée en 64 bits.
Le soucis vient peut être d'un problème plus global du support multi-arch sur mon ordi !

Bonjour et désolé du délai.
Malgré un

sudo apt -t stretch-backports install libdrm-amdgpu1 libdrm-nouveau2 libdrm-intel1 libdrm-radeon1 libdrm2 libegl1-mesa libgbm1 libgl1-mesa-dri libwayland-client0 libwayland-server

Rien n'a été mis à jour et Steam bloque toujours…

Rien avec apt-get -t stretch-backports…
Pour le conflit, j'ai essayé de remonter aux sources, en essayant d'installer la première lib qui casse au fur et à mesure : libgl1-mesa-dri:i386 puis libdrm-amdgpu1:i386 puis libdrm2:i386 et c'est la que ça coince.

user@debian:~$ sudo aptitude show libdrm2
Paquet : libdrm2                                        
Version : 2.4.95-1~bpo9+1
État: installé
Automatiquement installé: non
Multiarchitecture : même
Priorité : optionnel
Section : libs
Responsable : Debian X Strike Force <debian-x@lists.debian.org>
Architecture : amd64
Taille décompressée : 114 k
Dépend: libdrm-common (>= 2.4.95-1~bpo9+1), libc6 (>= 2.17)
Casse: libdrm2:i386 (!= 2.4.95-1~bpo9+1)
Remplace: libdrm2:i386 (< 2.4.95-1~bpo9+1)

Les versions 32 et 64 bits ne peuvent pas coexister, et je doute que ça soit la seule lib qui pose problème ainsi.

Les trois libs en questions étaient déjà installées, donc pas d'erreurs à ce niveau la.

Désolé, j'ai vraiment du mal avec le TUI de aptitude, je préfère amplement la version en ligne de commande !
J'ai bien essayé de bidouiller quelques trucs, mais à chaque fois je retombe sur un conflit d'une lib qui ne peut être en 32 bits et en 64 bits à la fois…
Je dois avouer que je sèche complètement là !

Je n'ai pas utilisé le pinning non, le dossier preferences.d n'existe même pas.
Sinon je n'ai pas trouvé grand chose d’intéressant via le TUI d'aptitude.

C'est possible que j'ai un jour utilisé les dépôts backports, mais je ne me souviens pas avoir volontairement changé la version de mon noyau…
Après j'ai installé cette distrib en Avril 2018, et je débutais sur linux et encore plus sur Debian, donc j'ai pu faire un truc sans m'en rendre compte, même si ça m’étonnerais.

il a alors des lib plus récentes que nécessaires et les dépendances sont alors cassées

Dans ce cas, aptitude ne me proposerait-il pas de retrograder les paquets en question ? Car là il ne le fait pas.

Au passage, j'avais déjà eu un problème de ce type avec Wine et j'avais fini par abandonner, mais comme steam comprend maintenant Proton, basé sur Wine, il pourrait y avoir un rapport ?

Visiblement, aucun paquet n'est gelé, on peut donc exclure cette hypothèse.
Sinon c'est une installation de Stretch de base.

Edit: Après ajout des dépôts backports et mise à jour, j'ai retenté une installation de steam via les dépôts officiels, et voila le résultat.

user@debian:~$ sudo apt install steam
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation : 

Les paquets suivants contiennent des dépendances non satisfaites :
 steam:i386 : Dépend: libudev1:i386 mais ne sera pas installé
              Dépend: libgl1-mesa-dri:i386 mais ne sera pas installé
              Dépend: libgl1-mesa-glx:i386 mais ne sera pas installé
              Recommande: zenity:i386
              Recommande: libxss1:i386 mais ne sera pas installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

J'ai par la suite pu installer le paquet libudev1:i386 avec sudo apt-get -t stretch-backports install libudev1:i386 mais pas libgl1-mesa-dri:i386 ni libgl1-mesa-glx:i386, toujours a cause des soucis de dépendances, respectivement

Les paquets suivants contiennent des dépendances non satisfaites :
 libgl1-mesa-glx:i386 : Dépend: libgl1:i386
                        Dépend: libglx-mesa0:i386 mais ne sera pas installé

Pour libgl1-mesa-glx:i386 et

Les paquets suivants contiennent des dépendances non satisfaites :
 libgl1-mesa-dri:i386 : Dépend: libdrm-amdgpu1:i386 (>= 2.4.90) mais ne sera pas installé
                        Dépend: libdrm-intel1:i386 (>= 2.4.38) mais ne sera pas installé
                        Dépend: libdrm-nouveau2:i386 (>= 2.4.66) mais ne sera pas installé
                        Dépend: libdrm-radeon1:i386 (>= 2.4.31) mais ne sera pas installé
                        Dépend: libdrm2:i386 (>= 2.4.75) mais ne sera pas installé
                        Dépend: libelf1:i386 (>= 0.142) mais ne sera pas installé
                        Dépend: libllvm6.0:i386 (>= 1:6.0~svn298832-1~) mais ne sera pas installé

Pour libgl1-mesa-dri:i386.

Ça avance, c'est déjà ça !

Mince, je viens de me rendre compte que j'ai oublié de préciser ça dans mon post, voila mon matos :
C'est un laptop Lenovo, avec un processeur Intel core I5, un SSD 120 GO et un HDD de 1TO, et 4GO de ram.
Je n'ai pas de carte graphique donc j'utilise (normalement) les drivers pour l'IGP de mon proco.

Ensuite, c'est étrange d'avoir un "vieux" noyau 4.16 et un sources.list qui n'indique pas le dépot backport.

Ah ? Je devrais donc ajouter les dépôts backport à mon sources.list ?

Enfin, tu indiques que tu as testé des solutions mais lesquelles ?

Je pourrais pas toutes les lister, mais pas mal de celles sur lequel on tombe en cherchant sur internet des problèmes qui ressemblent aux miens, comme le sudo dpkg --add-architecture i386, la création de certains liens symboliques (ou je n'avais pas les fichier à lier), ou l'installation de certains paquets (impossible à installer ou non trouvés en général).

Euh, je ne me souviens pas d'avoir réglé cette option pour certains paquets et pour avoir regardé plus précisément quelles libs posent problème, elles bloquent un peu toutes, donc c'est étrange.
Et ce message apparaît a chaque conflit et jamais je n'ai eu de soucis qui venait de là, donc c'est vrai que je ne me suis pas penché la dessus, mais je suis preneur d'une idée pour fouiller cette piste !

J'avais déjà essayé, ça ne change rien…

Ici le steam.list est la car j'avais tenté l'install depuis le .deb, mais depuis les depots (en supprimant le steam.list) et c'est pareil, sauf que le soucis survient direct à l'installation, et plus au lancement.
Pour ce qui est des conflits, j'ai essayé d'approfondir le truc, et a chaque fois je tombe sur des conflits, et quand j'essaye avec aptitude, il me propose de dégager plus de 600 paquets donc je suppose que c'est en conflit avec une lib essentielle.

Bonjour,
Après vérification des logs, il s'agissait bien d'un problème de permissions.
Pour ceux qui liront ce forum : attention, le fichier doit être propriété de root et surtout doit être en chmod 700, un chmod 777 ne marchera pas !
Au final voici mon script, nommé 99-backup.sh, placé dans /etc/NetworkManager/dispatcher.d/

#!/bin/bash

heure=`date +%H`
if [ $heure -ge 18 ] && [ $heure -lt 23 ] #vous pouvez changer l'heure de début et de fin de l’exécution du script
then
        echo yes
        IF=$1
        STATUS=$2
        if [ "$IF" == "wlp2s0" ] #à remplacer par le nom de votre interface
        then
                case "$2" in
                (up)
                        su user -c "bash /home/user/dev/scripts/backup.sh" #nom d'utilisateur et chemin du script à changer bien evidemment
                        ;;
                esac
        fi
fi

Ici je n'ai pas fait de vérification du réseau car je peux le faire de n'importe ou mais il suffit de vous aider du script originel de @ranDom pour le faire.
Merci à tous, c'est un sujet résolu !

Merci pour ce script, je pourrais le simplifier vu que je peux synchroniser mes données de n'importe où.
Seulement, quand je place ce script dans le dossier indiqué, cela ne marche pas (j'ai bien sur adapté le code à mon réseau).
J'ai donc essayé de faire un appel sans condition a un simple - echo redirigé vers un fichier mais rien, même après un redémarrage du service…
J'ai comme l'impression que NetworkManager ne fonctionne pas normalement chez moi, c'est déjà la deuxième solution avec ce service qui ne marche pas, pourtant c'est bien lui qui gère le réseau car quand je le redémarre je perd la connexion…
Une idée ?
PS: J'ai déjà réinstallé NetworkManager mais étrangement, après une désinstallation en mode simulation, je n'avais plus l'icone en bas de mon bureau mais j'avais toujours accès à internet, peut être est-ce dû au fonctionnement du mode simulation.

Bonjour,
Cette solution m’intéresse beaucoup mais je ne comprend pas, la commande
systemctl status network-online.target

Me renvoie systématiquement que le réseau est actif, par conséquent mon démon ne marche pas…
Aurais-je mal compris le fonctionnement de ce démon ?

Merci, ça peut être intéressant.
De toute façon, comme dit lus haut, je n'ai pas besoin de vérifier l'identité du réseau car ma box est configurée pour rediriger les requêtes rsync vers mon RPi.
Malgré tout, je pense que cette solution c'est un peu se compliquer la vie, mais je me renseignerai.

Juste si ça vous intéresse, voici mon dernier script:

#!/bin/bash

executed=$(cat executed.txt)
if [ "$executed" = "0" ]
then
        echo 2 > executed.txt
        while [ 1 ]
        do
                ping -c 1 google.fr
                if [ $? = 0 ]
                then
                        rsync
                        echo 1 > executed.txt
                        break
                fi
                sleep 1m
        done
fi

Il y a un cron qui remet le fichier avec un 0 dedans tous les jours a minuit et ce script est exécuté toutes les 10 minutes a partir de 18h.
Ainsi si l'ordi est éteint à 18h c'est bon et ca syncro qu'une seule fois par jour.
Le 2 dans executed.txt peut être remplacé par un fichier lock mais c'est dans l'idée.
Je pense qu'on peut clore le sujet car deux solutions ont été proposées pour des besoins différent, c'est parfait.
Merci à tous,
Raphael

Intéressant, j'irais creuser.
En attendant, j'utilise ce code :

#!/bin/bash
while [ 1 ]
do
        ping -c 1 google.fr
        if [ $? = 0 ]
        then
                rsync
                break
        fi
        sleep 1m
done

Qui me paraissait la solution la plus propre à ma disposition.
Je regarde votre lien mais je ne sais pas si il est valable car je dois effectuer ça une seule fois par jour a partir d'une heure donnée.
Merci quand même,
Raphael

Intéressant, j'irais creuser.
En attendant, j'utilise ce code :

#!/bin/bash
while [ 1 ]
do
        ping -c 1 google.fr
        if [ $? = 0 ]
        then
                break
        fi
        sleep 1m
done

Je n'avais en effet pas vu ce topic (malgré des recherches), mais la solution n'est pas celle que je souhaite, mon script ne doit pas s’exécuter au démarrage d'une interface mais à une connexion à un réseau wifi (mon ordinateur n'ayant pas de port rj45).

Peu m'importe le réseau sur lequel je suis, j'ai des redirections sur les ports 21 (ssh), 80, 443 (http/https) et 873 (rsync) donc je n'ai pas besoin d'être sur le même réseau.
Et oui mon script va regarder si il est connecté à un réseau mais la question est comment faire ?
Y a-t'il une autre solution que de faire avec ping et grep ?

Oui oui, un echo au debut du fichier sans condition c'est ce que j'ai fait.
J'ai aussi donné les droits d'execution à tous les utilisateurs au cas ou.
Si j'éxecute le script à la main le comportement est bien celui attendu.
Et oui mon script est au bon endroit, donc je pense que le problème ne vient pas de la, je pense plutot que le comportement de ce dossier n'est pas celui que l'on recherche.

Merci pour cette réponse, j'ai donc placé un script tout simple (juste un echo redirigé vers un fichier) dans /etc/network/if-up.d (légèrement différent mais cela doit dépendre des distributions) mais malgré plusieurs connexions et déconnexions il n'y a rien…