Olivier a écrit 889 commentaires

Bonjour,

il va te falloir en effet jouer sur le xorg.conf. https://www.google.com/search?q=xorg.conf+dual+screen+intel+nvidia donne des exemples, et il a notamment ceci http://askubuntu.com/questions/142915/intel-graphic-chipset-and-nvidia-geforce-gtx560 qui correspond assez bien à ta demande.

Par contre, attends toi à devoir passer en mode console (ctrl+alt+f1), et à devoir arrêter le service graphique en force (sous mint, il me semble que c'est "systemctrl stop mdm"), dans le cas où ton xorg.conf fait tout planter au démarrage !

Entraînes toi un peu avant …

Merci pour les infos, continue tes publications STP !

• Le "metric" est une information donné par la personne / le programme qui configure la table de routage.
• Elle permet de dire à la pile TCP/IP que pour aller à tel sous-réseau, cela va "coûter" un certain nombre de "bons", à savoir de passage par des routeurs différents.
• Plus le "metric" est élevé, plus l'utilisation de la route est longue, donc moins la pile TCP/IP va l'utiliser.
• C'est donc une méthode afin de donner une priorité à une route plutôt qu'à une autre.

• A priori, seul un humain sait comment sont configurés les réseaux de la machine, donc c'est normal que cette information soit à fournir lors de la création d'une route (route add xxxxx).

• Ce qui est bizarre dans ta configuration, c'est le "metric = 3" dans la ligne :

0.0.0.0 192.168.0.1 0.0.0.0 UG 3 0 0 enp3s0

la 1ère colonne indique que c'est la règle pour la route par défaut, c'est à dire, celle à utiliser lorsque aucune des autres routes ne fonctionne.

Personnellement, je m'attendrai à un "metric = 0" dans ce genre de configuration.

Il est probable que cette information vienne du /etc/network/interfaces

Après avoir fait le démontage, voir éventuellement lancé les commandes LVM qui vont bien, il est recommandé de faire le "echo 1 > /sys/block/sdb/device/delete". En effet, cela permet de couper électriquement le moteur du disque, donc tu n'endommageras pas les plateaux/têtes au moment où tu vas physiquement déconnecter les câbles.

Effet collatéral chez moi : Lorsque j'hiberne la machine (desktop) après une telle commande, la machine ne veut plus sortir d'hibernation.

J'utilise aussi sur quelques machines (Debian Testing http://pipelight.net/cms/install/installation-debian.html ). Pipelight permet, de plus, de faire fonctionner autre chose que du flash, comme par exemple du silverlight. La liste complète est là : http://pipelight.net/cms/installation.html

Certes, c'est complètement non-libre. Mais cela peut rendre services, notamment pour certains sites de replay vidéo.

Coté technique, c'est assez intéressant: Un répertoire ~/.wine-pipelight/ est créé, dans lequel va tourner une version spéciale/patchée de wine. C'est dans ce répertoire que vont être installés les différents plugins à utiliser.

Sous Debian, la commande (root) "pipelight-plugin --update" permet de forcer la mise à jour d'un script, qui connaît quels sont les dernières versions à jour des plugins. Aussi, lors du démarrage du navigateur et de l'utilisation de plugins, le "wine-pipelight" fait, si nécessaire et automatiquement, la mise à jour des plugins.

Personnellement, je fais précéder mes commandes "apt-*" ou "aptitude" par

nice -n 20 ionice -c 3

Le gestionnaire de paquet a le moins de priorité CPU et I/O (disque dur) possible.

Pour les mises à jour, j'ai un alias :

alias aptitude_update='nice -n 20 ionice -c 3 aptitude update && nice -n 20 ionice -c 3 aptitude full-upgrade --without-recommends && nice -n 20 ionice -c 3 aptitude clean && nice -n 20 ionice -c 3 aptitude autoclean'

Bonsoir,

tu as tapé :

root@francois-kubuntu:~# cd /media/ ls -la
root@francois-kubuntu:/media# cd francois ls

Alors que je t'ai marqué :

cd /media/

ls -la

cd francois

ls

J'aurais peut-être dûs le mettre en gras, rouge et souligné, mais à priori tu n'as pas lu le commentaire au début :

(après chaque commande, il faut appuyer sur la touche "enter"):

Il y a des warning:

7.044 intel(0): RGB weight 888
7.044 intel(0): Default visual is TrueColor
7.044 intel(0): Unknown chipset
7.044 intel(0): Relaxed fencing disabled

=> Chipset non complètement reconnu par le driver ?

7.994 Depth 24 pixmap format is 32 bpp
7.994 intel(0): cannot enable DRI2 whilst forcing software fallbacks
7.994 intel(0): Allocated new frame buffer 1920x1080 stride 7680, untiled

=> Impossible de charger un firemware/module DRI2

8.180 intel(0): Disabling Xv because no adaptors could be initialized.
8.180 intel(0): direct rendering: Failed

=> Pas d'accès rendu direct

et une erreur:

8.432 AIGLX: Screen 0 is not DRI2 capable
8.432 AIGLX: reverting to software rendering
8.477 AIGLX: Loaded and initialized swrast
8.477 GLX: Initialized DRISWRAST GL provider for screen 0

=> GLX passe au mode de rendu software. C'est probablement la raison pour laquelle l'affichage est ralenti.

Il y a pas mal de problème similaire sur le net:
https://www.google.fr/?q=AIGLX:+Screen+0+is+not+DRI2+capablele

A mon avis, il faut commencer par regarder du coté du chipset graphique qui ne semble pas très classique :

lspci | grep "VGA compatible controller"
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)

D'après https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782690 , le problème semble être corrigé en installant un morceau d'experimental :

I could nail down the issue a little. Installing
xserver-xorg-video-intel from experimental (with no need to upgrade
other components of the stack) is enough to fix it and get DRI2
support and full hardware rendering.

Comme dit plus haut, le problème vient du fait que ext4 prend en compte les droits d'accès à ta clé. Or, pour l'instant, et comme tu n'as pas encore créé de répertoire sur cette clé, une seule et unique personne peut y écrire : l'utilisateur "root".

Comme tu es sous KDE, voici la procédure à appliquer
- appuyes en même temps sur les touches "alt" et "F2"
- cela affiche une petite barre en haut
- tapes:
konsole
- dans la konsole, tapes (après chaque commande, il faut appuyer sur la touche "enter"):
sudo bash
- donnes ton mot de passe. Il est normal qu'il ne s'affiche ps à l'écran. Tapes sur la touche "enter" pour valider
- tapes
cd /media/
ls -la
- tu dois trouver un nom de répertoire qui est celui de ton login (exemple : "etiab"). Je suppose à partir de là que ton login est "etiab", à toi de le remplacer dans les commandes ci-dessous si ce n'est pas le cas
- tapes
cd etiab
ls
- là, tu dois voir un nom assez long, de type 02d2fs…. Tu vas donc taper le début de ce nom et appuyer sur ta touche "tabulation" (à gauche de la touche "a" sur un clavier azerty) :
cd 0d92fs suivit de "tabulation"
- à partir de maintenant, tu es sur la clé USB
- crée un répertoire quelconque. Exemple "data"
mkdir data
- autorise n'importe qui (donc toi) à écrire dans ce répertoire
chmod 777 data
- sort de la konsole
exit
exit

Voilà, c'est fini. Tu peux écrire sans problème dans le répertoire "data"

Peux-tu mettre sur http://pastebin.com/ (ou autre) le contenu des :
- /var/log/Xorg.0.log
- L'intégralité du résultat de "glxinfo"

Dans le glxinfo de ta Debian, on lit "OpenGL vendor string: VMware, Inc." Or, VMWare sert pour la virtualisation de machine.

Comment as-tu installé exactement ta machine ? Tu as commencé par faire un test en la virtualisant ?

A mon avis, tu devrais commencer par réinstaller les paquets qui sont liés à xorg et à mesa (l'implementation libre d'OpenGL):

apt-get install --reinstall xserver-xorg-video-intel libgl1-mesa-glx libgl1-mesa-dri xserver-xorg-core

sftp est fait pour transférer des fichiers. Il fait parti du package client ssh.

Pour faire du sftp avec un port non standard :

sftp -o Port=330X user@mon_serveur

La seul contrainte est d'avoir le serveur sftp d'activé sur la machine à distance. Pour une Debian/Ubuntu, le /etc/ssh/sshd_config doit avoir :
Subsystem sftp /usr/lib/openssh/sftp-server

Est-ce que l'installateur n'a pas besoin d'accéder au réseau, afin de télécharger des paquets, et qu'il ne le peut pas ?

Est-ce que depuis l'installateur tu peux afficher des pages web, ou faire un bête "ping linuxfr.org" ?

Est-ce que ton problèmes est que lorsque tu double-cliques sur une vidéo situé sur un partage samba, VLC se lance en affichant un message d'erreur ?

Dans ce cas-là, et si tu utilises un Debian / Ubuntu, tu dois installer le paquets "vlc-plugin-samba" : https://packages.debian.org/jessie/vlc-plugin-samba

simple d'emploi lorsque les deux utilisateurs sont derrière un NAT…

J'ai récemment voulu configurer une connexion de Jabber avec du Kopete (KDE) et pidgin, et bien que les deux machines soient dernière des NAT, il n'y a pas eu de problème.

La raison c'est STUN : un serveur externe aux deux machines qui sert de relais afin d'établir la communication des deux connexions UDP. Après, tout passe en direct d'une machine à l'autre

Or notre logiciel de statistique ne peux être installé sur un PC qui n’est pas équipé de ce système.

Je rêve, ou la prochaine question qu'allait poser la personne en face aurait été de te demander d'installer un logiciel sur ta machine ?
Un logiciel de médiametrie, très probablement closed source, dont on ne sait pas exactement ce qu'il va faire sur la machine, le type de données qui vont être extraites, combien de temps il va resté actif, etc … ?

Personnellement, si une personne inconnue me contacte par téléphone et me demande d'installer un logiciel que je ne connais pas, même pas j'accepterai ! :)

Perso, j'ai testé Pipelight sur du Debian Jessie/Testing en AMD64 et cela marche bien.

Par contre, il faut bien penser à retirer le paquet "flash-nofree", et à arrêter iceweasel. Et à vérifer en mettant "about:plugins" dans la barre d'URL qu'il ne reste plus que Pipelight.

Bonjour,

pour les barres de status, perso j'utilise
status-evar : https://addons.mozilla.org/fr/firefox/addon/status-4-evar/
the addon bar (restored): https://addons.mozilla.org/fr/firefox/addon/the-addon-bar/

Cordialement

Le message "gpg: importées : 1" semble indiquer que la clé a été importé.

Essaye un "gpg --list-key", tu devrais trouver ton contacte dans la liste des clés.

Les messages de warning sont a mon avis dus au fait que ton contact n'utilise pas de serveur de clé. Aussi, techniquement parlant, rien ne te prouve que cette clé est bien celle de ton contact.

Il est probable que c'est la détection du hardware qui pose problème, il faut donc tester quelques (ou plusieurs, voir toutes ensembles) combinaisons de paramètres, qui vont désactiver des fonctionnalités du kernel.

De têtes, il y a des trucs de ce genre qui fonctionnent pas mal
acpi=noirq
acpi=off
acpi_osi=linux
noapic
noacpi (attention, ce n'est pas la même chose)
pci=noacpi

Pour ce qui concerne les options ci-dessous, c'est assez particulier. Il s'agit d'agir sur la manière dont le kernel discute avec les disques durs et contrôleurs. Dans le passé, j'ai eu quelques machines assez "pénibles", qui ont nécessitées ce type de paramétrages (et tout spécialement "libata.force=noncq,1.5Gbps").
On trouve assez peu de documentation sur Internet à ce sujet :
libata.force=noncq
libata.force=noncq,1.5Gbps
libata.force=noncq,3.0Gbps
libata.noacpi

La liste complète est ici https://www.kernel.org/doc/Documentation/kernel-parameters.txt

Après une petite recherche sur Internet, il y en a qui ont trouvé des solutions:
http://ubuntuforums.org/archive/index.php/t-1662577.html
https://www.google.fr/?q=ASUS+X71SL+linux+kernel+parameters

J'ai eu le même problème de lenteur à l'arrêt de ma Debian Testing/Jessie il y a quelques temps. Le coupable était Samba.

Analyse :
- Au démarrage de GRUB, retire le paramètre "quiet" de la ligne de boot de ton kernel linux (ou alors, modifie à la main le "/boot/grub/grub.cfg" . Ainsi, tu verras tout les messages de démarrage de systemd.
- graçe à ceci, lors de l'arrêt de la machine, tu verras les messages d'arrêt de systemd. Il est probable que tu observes alors un timeout de 5 minutes pour samba (il y a un compteur qui décroît).

Solution:
- chez moi, le symptôme était que "/etc/init.d/samba" était lancé via systemd, et qu'il fait double emploi avec "/etc/init.d/smbd" et "/etc/init.d/nmbd"
- j'ai donc complètement désactivé "samba", mais laissé "smbd", "nmbd" et "samba-ad-dc" d'actif :

systemctl stop samba
systemctl disable samba
update-rc.d -f samba remove

A priori, je dirais que ce sont des connexions qui ont été ouvertes puis fermées, et dont l'OS attends encore la confirmation de fermeture. Le status est "CLOSE_WAIT":

# netstat -taupn
tcp      288      0 x.x.x.:123456       y.y.y.y:45659    CLOSE_WAIT  -
tcp       69      0 x.x.x.:123456       y.y.y.y:58918    CLOSE_WAIT  -

Si l'application coté Linux s'est déjà fermée, alors 1) il n'y a plus de PID pour gérer cette connexion, et 2) il n'y a plus d'utilisateur.

Nethogs affiche alors "?" pour le PID et "userID = 0 = root" pour l'utilisateur.

Rien d'anormal donc. Ce type de connexion se fermerons toutes seules au bout du timeout tcp/ip (quelques dizaines de secondes).

Il y a 1 mois, j'ai commencé à me faire mon propre liceCD / liveUSB à partir de Debian et de ceci http://l3net.wordpress.com/2013/09/21/how-to-build-a-debian-livecd/

Le tutoriel est bien fait, et c'est facile à mettre en oeuvre:
- à la base, il faut quand même avoir une distribution Debian d'installé. Il est probable que tu puisses faire la même chose avec d'autres distributions, recherche sur Internet
- pour les tests, je fais booter une virtualbox sur le liveCD créé
- le gros interêt, c'est que tu peux choisir d'installer les paquets que tu veux : interface graphique ou non, outils de surf ou non, serveur SSH, SMB, NFS, etc…

C'est vraiment très puissant.

pour que linux se developpe,il faut penser aux débutants

Juste une petite remarque : Tu dis installer une Debian Jessie, donc il s'agit de la version testing de Debian. Son publique principal, ce n'est quand même pas les débutants.

Personnellement, je l'utilise depuis 10 ans sur toutes mes machines, j'en mets même chez des utilisateurs peu habitués à Linux, mais c'est moi qui en assure la maintenance.

Debian Testing n'est pas à mettre en toutes les mains, elle n'est pas aussi stable que la Debian stable (d'où son nom), et épisodiquement, il arrive qu'il y ait des trucs qui ne se passent pas super bien lors des mises à jours. Auquel cas, c'est là où un utilisateur un peu plus averti est nécessaire.

Comparé à l'environnement Windows, je pense que tu n'irais pas mettre entre les mains d'un débutant une pré-release de Windows 10…

Ta solution pourrait éventuellement marcher. Éventuellement, parce qu'un .deb, ce n'est pas juste une archive, mais aussi des scripts, qui doivent être exécutés dans un chroot

Nous sommes bien d'accord sur cela. Mais vu les problèmes annoncés, et notamment celui du login en TTY1 qui ne marche pas, je suppose que la "nouvelle" libc installée est incompatible avec le reste de l'OS (ie: des softs installés sur la machine). Dans ce cas, un chroot + exécution de script (qui utiliserait la libc déjà présente), n'a pas de chance de marcher.

Perso, avant ta solution bourrin, je tenterai plutôt le rescueCD + chroot, justement.

J'ai des gros doute que le chroot puisse lancer le bash/dash/sh/autre qui se trouve installé sur la machine. A mon avis, la libc installée fera planter tout les programmes qui sont linké avec l'ancienne libc.

D'où l'idée de n'utiliser que des softs "externes" aux applis installées (ceux du livecd/liveusb).