Ils le sont déjà, à mon avis.
Il existe, par exemple, un paramètre acpi_osi=Linux qu’on peut ajouter au boot dans grub.
Peut-être qu’un autre paramètre bien choisi peut régler définitivement le problème.
EDIT
Ce qu’en dit FEDora (je ne sais pas du tout si ça concerne le cas discuté ici)
…
acpi_osi=! acpi_osi='Windows 2009'
…
…
pcie_port_pm=off
…
J’ai essayé Bumblebee et le pilote proprio déjà, mais parfois au lancement de optirun openshot (c’est un exemple), j’obtenais un message d’erreur de second card GPU non détecté…
Pourtant quand je lance une appli DRI_PRIME=1 openshot, tout fonctionne a la perfection, c’est vraiment juste au boot ue parfois sans raison la Nvidia est active…
En faite je suis allé sur Sid parce que j’ai vu sur différents forums (anglais notamment) que c’était la méthode conseillée.
Testing > Sid
Stable > Testing > Sid (faire autant d’upgrade me parait un peu ""casse-gueule pour la stabilité sur le long terme).
Et pour Siduction, j’avais l’intention de l’installer, puis je me suis dis, quitte a choisir, autant prendre une Debian pure sans surcouche de quoi que ce soit.
Peut-être une erreur de ma part de penser ainsi.
Cette modif acpi_osi=Linux je l’avais faite sous mint mate, pour résoudre un soucis de mauvaise gestion de ventilo.
Le ventilo moulinait constamment malgré que les sensors detectaient des températures basses.
Mon.bios est Insyde H20 (réputé pour être pourri visiblement d’après ce que j’ai vu sur internet).
J’ai fais une tentative, j’ai activé temporairement les dépôts expérimental, et j’ai récupéré le dernier kernel en date (4.10.) et depuis le problème semble résolu, ça fait depuis un jour que j’ai fais la manip et tout a l’air de rentrer en ordre, mais je crie pas victoire trop tôt quand même.
Je sais que c’est du bricolage mal fait et vivement déconseillé, mais ça porte ses fruits on dirait.
Et même le pc chauffe moins, je tourne dans les 42° contre 48-52° avant l’upgrade du kernel.
Je sais que c’est contre courant de faire ce genre de manip et que ça rend instable tout mon système, mais je détecte pas de bugs depuis l’upgrade et je suis repassée évidemment sous la branche Sid depuis.
EDIT y a eu aussi une mise à jour du pilote nouveau (via les dépots Sid), alors je sais pas si l’amélioration notable vient de ça, mais le pc est vraiment transformé, gagner 10° je trouve ça colossal… et le problème avec la Nvidia a l’air résolu à l’heure actuelle… à voir sur le long terme, ou peut-être que le l’ancienne version du pilote nouveau était connu pour ce bug, mais j’ai rien trouvé malgré mes recherches… peut-être ais-je mal cherché aussi…
En effet, l’ajout des dépôts experimental est vraiment un très très mauvais choix !
Je ne suis pas étonné que ta situation se stabilise, telle que tu le décries, après suppression de ceux-ci.
Par contre, tu te retrouves quand même avec une distrib “bancale” !
Pour avoir la Sid, pas besoin de commencer par Stable/Testing pour dist-upgrader …
Il est possible d’avoir l’image iso officielle de telle manière, par exemple :
http://ftp.fr.debian.org/debian/dists/sid/main/installer-amd64/current/images/netboot/
par contre, c’est la version mini.iso, ni + ni - !
L’avantage de la Siduction est que c’est “packagé” de manière à être fonctionnelle, comme dans le contexte de la Debian Stable actuelle, tout en proposant dès le départ une Sid. Elle s’administre exactement pareil. Après ce qui change, c’est la méthode d’installation - que je trouve très spécifique, du moins pour la version 2016. Sachant qu’il vient de sortir une nouvelle version stable 2017
Par contre, je n’aime pas les choix esthétiques - j’espère qu’ils sont mieux avec la v2017 … mais c’est comme le reste, c’est changeable aisément !
Personnellement, je trouve plus agréable de fonctionner sur une Sid(uction?), qu’une Stable - même si cette dernière à l’avantage d’être plus relaxe sur le suivi, et les màj. Avec une Sid, c’est un impératif de les suivre semaines après semaines 
Juste d’autres réflexes !
Mauvais choix dans le sens où contrairement au dépôt Sid (Unstable) qui porte mal son nom, le dépôt Experimental est lui vraiment “expérimental”… 
Mais bon après tout, il est “pin-é” par défaut à 1, donc à moins d’aller vraiment chercher les paquets soit même et forcer l’installation de ceux-ci en provenance du-dit dépôt, il ne présente pas plus de risques que ça ; le risque est encore une fois entre la chaise et le clavier 
Celà dit, je suis d’accord pour dire qu’il vaut mieux éviter les paquets en provenance de ce dépôt, novice ou pas.
Quelle est la différence entre une Sid et une Siduction (sans vouloir diverger dans ce sujet)?
Niveau système : aucun … la Siduction a vraiment une base Sid.
Ce qui change, ce sont certains outils installés par défaut, - ça fourmille de petits outils + ou - appréciables - parfois très intéressant, et l’esthétique choisi.
je sais que les dépots experimental c’est a éviter à tout prix, surtout pour le kernel, qui est la colonne vertébrale de l’OS. mais je voulais voir si avec un kernel + récent, le problème disparaitrait ou non, et la réponse est oui… pour un kernel en court de développement ça tourne d’ailleurs très bien je suis étonnée.
je sais que je joue avec le feu, et que je déstabilise ma Debian avec ce genre de manip, mais j’en assume les conséquences si je devais en avoir dans un futur proche ou lointain.
je connaissais pas cet iso, 38 Mo en effet c’est du minimal pur.
faudrait que j’essaies en machine virtuelle cet iso, parce que l’installation doit être + complexe j’imagine.
mais si ça peut m’éviter de passer par une Testing pour upgrader en Sid, ça serait tout bénéf.!!!
Siduction m’avait plut et j’avais aucun problème graphique en live usb contrairement au live usb de Debian (plusieurs testés).
après je partais du principe
"“pourquoi utiliser par exemple Lbuntu quand on sait que la base c’est Debian, autant prendre une Debian Lxde”", et pour Siduction, je me suis faite la même réflexion, autant prendre la vraie Sid, je pense comme une novice, j’ai pas encore tous les réflexes comme vous qui êtes sous Linux depuis des dizaines d’années.
j’utilise la Sid pas pour être au top des logiciels à jour, mais pour le principe ““rolling-release”” suffit de mettre à jour régulièrement notre Sid, et on a pas besoin de faire des upgrade lors de nouvelles sorties de release.
j’ai abandonné w10 justement à cause de ça, trop d’upgrade qui rendent le pc instable, alors sous Linux je voulais avoir ce côté d’un OS mis à jour constamment, c’est pour ça aussi que Manjaro m’attire énormément, à défaut d’être trop nulle pour installer Arch.
je savais pas où poster le message, ici ou sur la partie scindée, vu que je suis un peu hors sujet…!!!
Pas seulement pour le kernel mais pour tous les paquets en général, à prendre vraiment avec des pincettes. Après je te dirai tant mieux si ça marche pour toi Etant en Sid également, je teste parfois certains paquets en provenance du dépôt Experimental, notamment Firefox,Chromium, Thunderbird et… le kernel
Eh ben chez moi le 4.10 présent dans ce dépôt c’est tout simplement une catastrophe pour l’instant…
Celà dit, l’essentiel avant tout, que tu sois en Sid uniquement ou que tu pioches même dans Experimental, c’est qu’à chaque fois que tu fais une MàJ ou que installes un nouveau paquet, tu vérifies que tout fonctionne bien et SURTOUT que tu deviennes à l’aise avec la console pour pouvoir rétrograder à la version antérieure en mode secours un ou plusieurs paquets si ça ne marche pas… C’est le b-a-ba pour se sortir de la m**de.
Pas forcément plus difficile, ça dépend de ton niveau de connaissance, mais vu la taille tu risques de te retrouver en mode console à mon avis, à toi de voir si tu es suffisamment à l’aise pour travailler en mode terminal…
C’est pas une mauvaise réflexion au contraire, mais avant tout le meilleur reste d’essayer et voir ce qui te convient le mieux, et bien sûr bien lire les docs sur la distribution qui t’intéresse, ça fait des tonnes de pages et ça prend du temps, mais une fois que tu maîtrises ta distrib après c’est finger-in-the-nose pratiquement ; je dis pratiquement parce que bon c’est quand même impossible malgré tout ça de tout maîtriser au bout des doigts…
Attention ça c’est un faux-ami. Ce que l’on fait avec :
# apt-get upgrade
ce sont bien des MàJ régulières.
Mais ce que l’on fait avec :
# apt-get dist-upgrade
correspond bien à des MàJ comme lors de nouvelles releases. Ce sont des MàJ qui ne peuvent pas se faire sans installer ou supprimer d’autres paquets/dépendances… Par exemple lorsque tu es en Debian Stable, passer d’une ancienne Stable à une nouvelle se fera forcément par un “apt-get dist-upgrade” entre autre…
Donc méfies toi bien également, etant en SID, lorsque tu fais cette commande, vérifies bien avant d’accepter ce qui est installé comme nouveau paquet et surtout ce qui est parfois proposé à suppression…
c’est vrai que d’un pc à un autre, le kernel se comporte d’une façon différente.
chez toi, c’est la catastrophe, alors que chez moi ça tourne mieux que le 4.9.0.2
pour le moment j’ai jamais eu le moindre soucis après des maj, jamais eu besoin de rétrograder, je sais qu’un jour ça m’arrivera, mais j’ai bien lu les doc et forums qui expliquent comment se sortir de la panade quand elle nous pend au nez.!!
si c’est une installation façon Arch, ça va être coton, j’ai réussis à installer Arch mais le résultat était décevant, j’ai du faire plusieurs boulettes ce qui a rendu l’OS instable, et inutilisable.
avec Debian je me sens vraiment à l’aise, même si je suis pas une pro, mais je la trouve simple à maintenir à jour, stable, solide, et peu gourmande.
j’ai même installé une Debian Jessie Lxde justement sur l’ancien pc Acer de ma mère qui était sous XP et qui ramait comme c’est pas permis, il lui sert de roue de secours en cas de plantage de son w7.
mais quand je lui ai expliqué l’essentiel, elle m’a avoué que le pc était transformait, une vraie petite fusée, malgré ses 12 ans.
oui je fais toujours un
et je regarde toujours ce qui sera installé, et-ou supprimé.
mais jusqu’à maintenant, j’ai jamais eu de paquets supprimés lors des maj.
j’ai aussi peut-être moins de logiciels que toi, j’ai vraiment l’essentiel, et le basique.
et tous les jeux gnome installé d’office, ça par contre c’est cool, j’aime bien pour tuer le temps quand les vidéos s’encodent avec OpenShot.
le seul regret que j’ai avec Debian, c’est après l’installation, je supprime certains paquets inutiles, comme par exemple thunderbird (je préfère Geary, + simple, il va à l’essentiel sans superflu), et à la suppression de thunderbird, on me propose d’installer evolution, c’est dommage de pas nous laisser le choix, et nous forcer à installer autre chose.
ou je connais pas la technique pour contourner la chose, ce qui m’étonnerait pas
Non, il n’y a pas de règles et normalement c’est le contraire : les nouveaux kernels intègrent de nouvelles fonctionnalités ou les améliorent pour les pc récents mais bon quand c’est dans Experimental ou Sid c’est encore en phase de dev…
Mon PC est un Vaio de 2011. C’est pas la cata, mais j’ai des bugs avec le 4.10 (à noter qu’il est toujours en rc actuellement, et ça fait un bout de temps qu’il est “coincé” dans Experimental celui-ci, car depuis que je suis les arrivées de kernel dans ce dépôt en général ça migre vite vers Sid) : plantage en sortie de veille, bugs avec le bureau Gnome, segfaults dans le journal système qui causent des crash de certaines applis… Bref c’est comme ça, ça viendra…
Ça c’est pas possible, thunderbird est indépendant de evolution et vis-versa, et en principe evolution est installé d’office avec Debian, enfin du moins avec Gnome, après avec les autres bureaux je ne sais pas… Ou alors il y a une question de dépendances “automatiques” à contourner… D’autre part certains paquets comme “evolution-data-server” sont impossibles à supprimer car faisant partie intégrante de Gnome par exemple, ce ne sont pas plutot ces paquets auxquels tu fais référence?
Mais bon pour ce point il est préférable d’ouvrir un autre sujet si tu y tiens vraiment…
EDIT : et surtout pour finir le sujet, et après notre discussion en MP, à l’avenir penses bien à faire des sauvegardes régulières et ne pas faire de mises à jour surtout de paquets qui sont en général relativement importants lorsque tu as un travail super important à finir, si tu sautes les MàJ d’un jour voir deux, trois c’est pas très grave…
mon pc est de 2013, donc légerement + récent que le tien.
le kernel peut se comporter de façon différente via différents bureaux.??
toi Gnome = plantages
moi Cinnamon = stabilité exceptionnelle
oui depuis que je suis sous Sid, ça fait + de 2 mois, on est passé du 4.9.0.1 à 4.9.0.2.
mais Stretch va sortir avec le 4.10 je crois que j’avais vu, ils doivent le paufiner pour qu’il soit nickel pour la majorités des pc.
juste pour te montrer, voilà ce que j’ai.
sous Cinnamon, c’est Thunderbird installé d’office.
tu vas rire, mais je fais des sauvegardes quotidiennes.
sauf que là, j’ai eu énormément de déplacements pour aller chez les clients (300 km par jour, 6 jours sur 7), forcément avec la fatigue je passais peu de temps sur le pc, et les sauvegardes me sont un peu sorties de la tête, et cet oubli m’a été fatal…
oui je peux rester une bonne semaine sans faire des maj parfois, et ça a jamais tué ma Debian.
tout est mal tombé au mauvais moment, c’est la vie c’est ainsi…
Attention tu utilises mal les commandes avec apt-get :
# apt-get autoremove
doit être utilisé tout seul, il sert à supprimer les dépendances installées automatiquement (pour d’autres paquets que tu aurais installé manuellement…) et qui ne sont plus nécessaires, en gros pour faire un peu le ménage…
Dans ton cas tu dois utiliser :
# apt-get remove thunderbird
ou
# apt-get purge thunderbird
La première commande ne fait que désinstaller le paquet, la seconde le désinstalle et purge ses fichiers de configuration.
Ouvres un autre sujet si tu tiens à résoudre ça, étant donné que ça n’a rien à avoir avec le problème initial.
EDIT: correction, après test chez moi ça marche aussi directement avec apt-autoremove, autant pour moi… il y a une histoire de dépendances là-dessous.
d’accord donc je peux continuer à utiliser autoremove, et/ou purge pour purger paquet et fichiers de config.
c’était + de la curiosité en faite ^^
pour le moment je vais laisser, j’ai remarqué que ce ““problème”” apparaissait uniquement quand il y a qu’un paquet (pour la messagerie j’ai que Thunderbird, et il propose Evolution en supprimant le 1er)
mais en venant d’installer Geary, je peux supprimer Thunderbird sans que cette fois Evolution soit proposé à l’installation.
c’est peut-être pour nous permettre d’avoir un paquet pour chaque catégorie importante (mail, navigateur, vidéos, musiques, etc…) ou c’est réellement une histoire de dépendances.
mais c’est loin d’être dramatique ça
Bonjour,
Je joue pas mal avec des VM et c’est effectivement une bonne solution pour tester, sans risquer de ruiner l’installation de l’hôte.
J’utilise Vmware Player mais, AMHA, la remarque suivante s’applique à d’autres virtualisations.
Tester cet iso (ou un autre) dans une VM n’apportera aucune certitude sur le support de la carte graphique (ni par le driver propriétaire, ni par nouveau). En effet, la virtualisation met à disposition de l’OS “invité”, une machine physique virtuelle (nombre de coeurs, ram, HD, carte graphique…). Lorsqu’on utilise un périphérique de manière exclusive (clef USB par exemple), il faut le démonter de l’ordinateur “hôte”.
Sylvain
bonsoir.
merci pour ces précisions, j’ai un peu utilisé les VM, mais c’est vrai que ça ne permet pas de voir si le pc va supporter l’OS, notamment au niveau des firmware, c’est pour ça que les iso en live sont très pratiques ^^
pour revenir au problème initial de la Nvidia qui s’activait aléatoirement, je crois que je viens de trouver un élément de réponse en regardant via Synaptic.
le kernel d’origine 4.9.01 était installé, mais j’avais que le paquet Linux-image.
idem pour le kernel 4.9.0.2
hors quand j’ai mis le kernel 4.10 via le dépot experimental, il y a le paquet linux-image, mais aussi le paquet linux-headers.
et d’après mes recherches sur internet, j’ai cru comprendre que le paquet linux-headers permettait la compilation automatique avec les pilotes (graphiques notamment et pour les VM aussi).
ceci expliquerait alors mon problème avec les anciens kernel, et la résolution de ce meme problème via le nouveau kernel.??
ou j’ai pas trop compris.?? et je me mélange les pinceaux.???
Oui tu as besoin des paquets kernel-headers pour compiler les modules du noyau, notamment lorsque tu utilises le pilote propriétaire et/ou des VM avec VirtualBox par exemple…
ha donc linux-headers ne compile pas Nouveau.??
parce que c’est depuis que j’ai le new kernel avec linux-headers que mon problème s’est résolu.
c’est peut-être une coincidence aussi, ça je sais pas trop
Non, il ne s’agit pas de compiler le pilote en lui-même, les headers sont des en-têtes, et ils ne compilent pas le pilote Nouveau ou celui de nVidia, mais des modules pour le noyau afin que celui-ci puisse charger et travailler avec le pilote adéquat dès le démarrage du PC (enfin dès le démarrage c’est une description très succinte que je te fais là et je préfère préciser sinon certains vont me tomber dessus ).
Mais pour le pilote Nouveau tu n’as pas besoin des headers puisqu’il n’y a pas de modules à comipler, le pilote est pris directement en charge par le noyau…
ha d’accord je comprends mieux alors maintenant.
complexe ce petit kernel quand on y pense.
donc c’est grace au kernel lui-même, le 4.10 que mon problème s’est résolu, alors je vais bien rester avec lui, vu que tout ronronne.
si j’avais su j’aurais pas mis le linux-headers, mais je vais pas y enlever, c’est très bien comme ça, et ca mange pas de pain surtout…!!! je suis pas à 50 Mo près
Aucune idée, ptêt ben qu’oui, ptêt ben qu’non… Il aurait fallu regarder à l’époque avec les logs sous le kernel 4.9 et voir ce qu’il en retourne et/ou comparer avec les logs sous kernel 4.10.
Mais si les headers ont été installés c’est qu’ils ont été requis par un autre paquet, pour voir pourquoi ils ont été installés il faut regarder du côté du paquet “dkms” qui doit être installé car c’est lui qui s’occupe de compiler les modules…
Tu peux voir s’il est installé avec la commande suivante :
$ dpkg -l | grep dkms
Et si tu as un retour positif, tu peux voir de quel(s) paquet(s) il est la dépendance en faisant :
$ aptitude why dkms