troumad a écrit :Bonjour
Pour ce qui est de formateur Linux.. Moyen... On m'a juste dit, si tu ne présentes pas Linux, personne ne le ferra. Alors, j'en fais 20h/an. Je suis officiellement prof de math. Mon but est juste de montrer que ça existe et qu'on peux faire beaucoup de chose avec peu.
...
Bonsoir,
C'est très courageux de votre part et cela me rappelle de vieux souvenirs, le plan informatique pour tous.
Que vous ne soyez pas formateur Linux n'est pas une tare, nobody is perfect. Ça signifie juste qu'il faut être plus pédagogique et éviter une supposée maîtrise de la bête.
troumad a écrit :
...
Les manip improbables c'est avec mon ancienne carte. Donc, rien à voir avec la nouvelle, celle avec laquelle je travaille maintenant.
Ma carte est entièrement prise en compte : tourtes les partitions sont bien montées. Les nouvelles partitions, je les ai faite avec l'outil graphique de Mageia et j'ai modifié à la main le fstab de la raspbian
.
Le dh indique simplement le niveau de remplissage des partitions, pas la répartition des données. Malheureusement, pour le moment, je n'ai pas la place d'installer filelight sur ma raspberry. Comme indiqué par votre dernier point, il y a sûrement trop de logiciels graphiques installés : 3,7Go dans /
J'ai du faire d'erreur de croire que 4go suffirai largement.
...
Si je comprends bien, vous confirmez mon hypothèse: Vous avez créé les partitions, sur la machine Mageia, avant de booter le Raspberry sur sa carte SD toute fraîche.
Cela fait, comme mentionné précédemment, que la partition système n'a pas été étendue pour prendre toute la place disponible sur la carte SD. Quel que soit l'outil graphique utilisé, la commande réellement utilisée est la commande dd.
dd est une copie bit à bit, qui peut prendre de nombreux paramètres, mais qui s'affranchit du système de fichier.
Pour être à l'aise, quel que soit le système d'exploitation (Windows, Linux, OS X ou autres), un système de fichier à besoin de place (fichiers temporaires ...).
Après avoir fait le ménage comme indiqué par Ghislain (méthode très efficace), vous pouvez tenter de redimensionner les partitions pour faire plus de place à /.
Si votre utilitaire graphique le permet et que vous le maîtrisez, utilisez-le. Sinon, un gparted à installer sur votre tour devrait faire l'affaire (ne pas oublier de démonter la carte SD ).
troumad a écrit :
...
Pour ssh et le graphique, je peux transférer une application graphique si je le fais à partir de la session de l'utilisateur qui c'est connecté par ssh. Sinon, voici tous les messages que j'ai :
Code : Tout sélectionner
root@raspberrypi:/var/lib# echo $DISPLAY
localhost:12.0
root@raspberrypi:/var/lib# exit
déconnexion
troumad@raspberrypi:~ $ echo $DISPLAY
localhost:12.0
troumad@raspberrypi:~ $ su -
Mot de passe :
X11 connection rejected because of wrong authentication.
J'ai rajouté la ligne que vous m'avez indiquée dans le sshd_config du serveur. Rien de mieux.
...
ATTENTION, ÉLOIGNEZ LES ÂMES SENSIBLES DE DEVANT L’ÉCRAN.
Quant à vous, prenez une aspirine ou une bonne bière
Le comportement que vous rapportez est tout à fait normal. Vous devriez aussi le constater sur votre tour (sauf réglage par défaut).
Historiquement, le protocole X11 qui, dès l'origine, prévoit un fonctionnement déporté de l'affichage (à travers TCP/IP), considère que l'écran appartient à ................son propriétaire.
Le problème des debiannes et donc de ses dérivées comme Raspbian, Ubuntu, Xubuntu et autres, prennent l'utilisateur pour un débile profond qui ne sait pas ce qu'il fait. Le compte super-utilisateur root est donc verrouillé et il est impossible de s'y connecter (impossible n'étant pas français, c'est possible mais pas documenté).
Pourtant, il y a des actions et des commandes qui ne peuvent être faites que par root. comme il serait encore plus dangereux d'autoriser ces commandes pour tout le monde, on a recours à sudo qui permet de prendre, temporairement, l'identité de root.
Vous pouvez vérifier ceci en regardant le contenu du fichier /etc/passwd et du fichier /etc/shadow. Dans le premier, l'utilisateur root est bien décrit, avec son UID, son GID, son home, son shell. le champ mot de passe comporte un x qui masque le mot de passe et renvoie vers le fichier /etc/schadow.
Le fichier /etc/shadow comporte une * dans le champ du mot de passe crypté (2 ème champ). Cela signifie tout simplement login interdit car aucun mot de passe, une fois crypté, ne peut générer une étoile.
Ça va, on suit ? j'en vois un qui dort au fond de la classe, près du radiateur.
Deuxième notion à comprendre, est celle de l'autorisation mise en place par xauth (qui est installé d'office). Elle gère l'authentification de l'affichage (sous UNIX/Linux , en général, les commandes ou noms de fichiers en X n'ont rien à voir avec le porno mais avec l'affichage X11).
Si vous regardez dans votre home, avec la commande ls -a (-a comme all = tous les fichiers, mêmes les fichiers cachés qui commencent par un .), vous trouverez un fichier .Xautority.
Code : Tout sélectionner
pi@domotique:~ $ ls -a
.cache .gconf Pictures Templates .Wolfram Research
.config .gstreamer-0.10 .pip .themes .Xauthority
.asoundrc .dbus .gtkrc-2.0 .pki .thumbnails .xsession-errors
.bash_history Desktop .local .profile Videos .xsession-errors.old
.bash_logout Documents Music Public .vnc
.bashrc Downloads oldconffiles python_games .WolframEngine
si vous essayez de le visualiser avec un cat ou un less ou un more, vous aurez un avertissement que le fichier n'est pas un fichier texte mais un fichier binaire (si vous passez outre, vous aurez l'affichage de caractères bizarres).
Ce fichier se manipule avec la commande auth.
Si vous faites la même manipulation de regarder le fichier .Xautority dans le home de l'utilisateur root, vous découvrirez qu'il n'y en a pas. C'est logique, pourquoi un fichier d’autorisation d'affichage si le, compte est verrouillé ?
Code : Tout sélectionner
pi@domotique:~ $ sudo ls -a /root
. .. .aptitude .bash_history .bashrc .config .profile .vnc
pi@domotique:~ $
On ne va pas finasser mais tout simplement copier notre fichier .Xauthority vers /root/.Xauthority avec un simple sudo cp.
CECI PEUT CONSTITUER UNE FAILLE DE SECURITE (je ne crie pas mais j'insiste).
Maintenant si vous vous connectez avec ssh -X pi@votre_pi
et que vous lancez la commande sudo votre_programme_graphique &, cela devrait bien fonctionner.
J'ai fait tous ces tests, pas à pas, sur un Raspberry B+ et une tour sous Debian Jessie 64 bits.
J'ai installé X11-apps pour avoir un programme X11 léger pour les tests (xeyes, xclock).
Si un point n'est pas clair, n'hésitez surtout pas à poser toutes les questions nécessaires. Si cela fonctionne, venez aussi nous le dire afin de valider la réponse (pour les autres).
Bon courage.
Sylvain
Donc normal que après l'installation de quelques logiciel le update/upgrade ne passe pas 
