Vous n'êtes pas identifié(e).
En ligne
nous sommes tous différents ... c'est notre point commun ...
Association Debian-Facile - Les cahiers du débutant - ISO Debian-Facile - 3hg - nakeDeb
GNU/Linux©2006-2024
Hors ligne
Mais un dmesg | grep -i firmware ne me montre pas la prise en compte du chipset amdgpu intégré à mon proc,
Il serait peut-être bon de l'indiquer en gros quelque part, car c'est vraiment la misère, cette histoire...
Rappel : avant le changement de carte-mère et donc de chipset, je n'avais pas de problème avec l'iso d'il y a un mois environ.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
En ligne
Tu devrais pas utiliser grep pour ça, dmesg a des arguments exprès pour filtrer ses résultats
Merci pour cette info, que je découvre aujourd'hui !
Alors j'ai tapé ce que tu m'as suggéré mais comme je suis en console depuis une clé usb, je ne peux pas récupérer la douzaine de lignes qui sont sorties, à moins de les recopier caractère après caractère et j'ai un peu la flemme, je l'avoue, car il s'agit d'erreurs habituelles genre kvm: disabled by bios et ça ne va pas faire avancer le schmilblik.
Une suggestion : faire un micro-iso (avec un menu à plusieurs options éventuellement [test avec chipset ceci, avec cela] mais sans rien d'autre, parce que télécharger 2 Go pour rien, quand on a une connexion antédiluvienne, c'est pas glop) juste pour pouvoir tester ce qui passe et ce qui casse.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
En ligne
Seulement il y a 366 choses qui peuvent mal se passer, que je sache le seul moyen fiable de tester c'est d'essayer >_>
Oui et c'est bien pour ça que je suggère un micro-iso avec un menu aux 366 possibilités : ça irait plus vite pour télécharger et recopier sur clé un .iso de quelques dizaines de mégas plutôt qu'un énorme machin de 2 Go...
Dans ton cas, on dirait que le problème est que le serveur graphique ne se lance pas, donc l'information intéressante serait probablement le modèle de ta carte graphique. Mais vu qu'il y en a plein je saurai certainement pas indiquer le problème.
le serveur graphique ne se lance pas parce que le gpu n'est pas pris en compte.
dmesg | grep -i firmware ne me montre pas la prise en compte du chipset amdgpu intégré à mon proc,
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
otyugh a écrit :Seulement il y a 366 choses qui peuvent mal se passer, que je sache le seul moyen fiable de tester c'est d'essayer >_>
Oui et c'est bien pour ça que je suggère un micro-iso avec un menu aux 366 possibilités : ça irait plus vite pour télécharger et recopier sur clé un .iso de quelques dizaines de mégas plutôt qu'un énorme machin de 2 Go...
Je comprends pas ce que tu veux dire ; mais si tu veux aller concret, le projet est ouvert aux contributeurs et aux suggestions (le plus concret le mieux).
Pour la CG, je pensais plus que tu pourrai donner la sortie de
En ligne
jpt a écrit :otyugh a écrit :Seulement il y a 366 choses qui peuvent mal se passer, que je sache le seul moyen fiable de tester c'est d'essayer >_>
Oui et c'est bien pour ça que je suggère un micro-iso avec un menu aux 366 possibilités : ça irait plus vite pour télécharger et recopier sur clé un .iso de quelques dizaines de mégas plutôt qu'un énorme machin de 2 Go...
Je comprends pas ce que tu veux dire ; mais si tu veux aller concret, le projet est ouvert aux contributeurs et aux suggestions (le plus concret le mieux).
Je dis juste qu'un iso de test qui reste en mode console, sans X, sans tout le fourbi de LibreOffice et mille autres choses serait bien utile pour tester ce que j'appelle le premier niveau de la clé, il serait très léger et rapide à dl et à copier sur clé.
Et quand ça sera bon, on peut envisager de passer à X avec une base (une arrière-garde ou des fondations, appelle ça comme tu veux mais tu vois l'idée) saine -- là, ce n'est pas du tout le cas, la preuve :
Pour la CG, je pensais plus que tu pourrai donner la sortie de
lspci -d ::0300
09:00.0 VGA compatible controller: Advanced Micro Devices. Inc. [AMD/ATI] Picasso (rev c9)
Alors je vais voir dans /lib/firmware/amdgpu et là-dedans je vois bien le microcode pour Picasso, du coup je lance lsinitramfs -l /boot/initrd.img-blabla | more et je constate que le firmware Picasso n'est pas dedans.
Ceci explique peut-être cela.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Je dis juste qu'un iso de test qui reste en mode console, sans X, sans tout le fourbi de LibreOffice et mille autres choses serait bien utile pour tester
Qu'on lance la session graphique ou pas n'a aucune incidence sur le poids de l'ISO ; si elle est installé, l'ISO sera toujours aussi lourde à la fin ? Je vois pas trop l'intêret. >_<
Qu'elle se lance automatique ou pas aussi, tu as pu accèder au TTY sans problème non ? Je vois pas trop l'intêret comme ça de décliner. La version légère de debian sera toujours la netinstall à priori.
Dernière modification par otyugh (10-10-2020 14:36:10)
En ligne
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Mettez-le en gros sur la page de download.
C'est peut-être trivial à contourner, ça serait bête de clore en affirmant que quelque chose ne marche pas avec si peu de tests et de recherche ? Peut-être que le problème ne vient même pas de là après tout ^^'
Nous on a pas vraiment touché à la configuration graphique par défaut, on a juste inclu les drivers graphiques les plus courant. Il est probable qu'installer un kernel backporté ou installer le bon firmware aurait résolu ta situation. Faudrait chercher pour savoir (et ça implique d'avoir ta configuration sous la main).
C'est probablement pas spécifique à notre packaging, c'est plus probablement un souci que tu aurai eu sous n'importe quel debian. À priori les trucs ryzen sont récent et la debian stable a du mal avec le matériel récent. Ça semblerait logique qu'il y ait quelques p'tits incidents sur la route.
Dernière modification par otyugh (10-10-2020 17:53:54)
En ligne
Hors ligne
bonsoir jpt
on t'a déjà dit : avec ce proco, utiliser de préférence testing bullseye.
Rappel : avant le changement de carte-mère et donc de chipset, je n'avais pas de problème avec l'iso d'il y a un mois environ.
Je devrais l'écrire autrement : je n'ai pas eu de problème avec l'iso d'il y a un mois environ, sauf avec les consoles.
ou, comme tu l'as fait déjà aussi buster stable avec les backports.
Oui oui oui, mais je voulais une clé usb en plus, à côté, en cas de catastrophe.
Tout à l'heure j'ai téléchargé depuis le lien que tu m'avais communiqué il y a 3 semaines une "standard +firmware" avec noyau 5.8.0-2 mais je n'ai pas eu le temps de m'en occuper, fallait que je dépanne l'alim de la télé Philips d'un voisin, rien à voir avec les iso.
Et donc, comme j'avais été satisfait de l'iso d'il y a 3 semaines mais pas du tout de son installation sur une clé pour faire office de système (pas live), je voulais prendre la dernière en me disant que ça serait fatalement mieux, et j'aurais pu comparer, avant de vous en parler.
Mais non, car le changement de CM est intervenu entretemps, et on se souviendra de ce qu'on trouve chez Debian :
Contrary to our wishes, there may be some problems that exist in the release, even though it is declared stable.
source
Debian, ce n'est plus ce que c'était.
jpt a écrit :Mettez-le en gros sur la page de download.
C'est peut-être trivial à contourner, ça serait bête de clore en affirmant que quelque chose ne marche pas avec si peu de tests et de recherche ? Peut-être que le problème ne vient même pas de là après tout ^^'
Oui mais comme c'est un iso, on est plutôt pieds et poings liés, et c'est pour ça que j'avais pensé à un boot minimum et pas d'applis derrière, mais plutôt un menu avec plein d'options différentes, genre charger les fichiers du chipset xyz ?, etc.
Mais ce n'est peut-être pas une bonne idée...
Dernière modification par jpt (10-10-2020 19:23:19)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Dernière modification par Debian Alain (10-10-2020 19:30:45)
Hors ligne
tu te mets peut-être la barre un peu trop haut, non ?, jpt ?
C'est se mettre la barre un peu trop haut que de vouloir une clé usb fonctionnelle juste pour pouvoir se rattraper, au cas où pépin sur la machine ?
Je ne crois pas, non.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
C'est se mettre la barre un peu trop haut que de vouloir une clé usb fonctionnelle juste pour pouvoir se rattraper, au cas où pépin sur la machine ?
Je ne crois pas, non.
tu veux quoi ?
une clé d'installation ?
un live ? (on fait les deux en mme temps )
une sauvegarde de tes données ?
-- clonezilla.org --
tu as tellement bricolé que je ne sais plus loù tu en es ? ?? ,
normalement , le lien que je t'ai donné , c'est pour un live , non ?
N.B.: un live permet de "se rattraper, au cas où pépin sur la machine" .
normalement tu en as déjà un .
-- lives de testing --
-- de l'usage de dd pour créer une clé bootable --
-- de l'usage de cp pour créer une clé bootable --
Hors ligne
--
Jc E
Hors ligne
tu as tellement bricolé que je ne sais plus où tu en es ???
t'inquiète, moi je sais.
Je suis en plein brouillard...
D'abord on a vu plus haut que l'iso 6.1 de DF n'est pas capable d'aller jusqu'au bureau.
Ensuite j'ai téléchargé hier chez Debian une testing 5.8.0-2 qui plante violemment dès son boot dans Virtualbox, genre kernel panic avec tous ces chiffres qu'on est incapables de décoder.
Et enfin, j'avais ces derniers temps des pertes du sda1, que j'avais attribuées à un câble CM--DD trop tendu (en zappant le fait que comment cet animal faisait pour booter, alors ?) car, l'ayant détendu, j'ai passé la semaine sans plus de soucis.
Et ce matin rebelote, j'allume la machine et tous mes montages sophistiqués sont à la rue, la partoche sda1 s'appelant sdb1 et sdb1 s'appelant sda1, un truc de malade.
Reboot et c'est bon, je peux bosser dans VBox, qui m'oblige à rebooter pour activer un paramètre dans le bios, ce que je fais et au redémarrage qui suit c'est encore la pagaille sda1<>sdb1, qui m'impose encore un reboot pour que les choses rentrent dans l'ordre.
Je ne sais vraiment plus quoi faire et suis complètement découragé.
Tiens, regarde :
Normalement le système c'est le ssd de 240 GB (au milieu de la liste) et les deux autres c'est les données.
Et j'ai malheureusement l'impression que ce problème serait lié à la nouvelle CM. Mais comment expliquer que le système boote ? Ah, j'ai une idée : à l'allumage, le bios trouve d'abord le 1er 2Go donc il l'appelle sda, puis il trouve le ssd bootable et l'appelle sdb, sdc restant sdc.
Et c'est confirmé par les premières lignes de dmesg :
Là je mets ces 3 lignes en ordre chronologique. Pourquoi le premier s'appelle-t-il sdb ? Quel foutoir...
Pagaille confirmée par l'ordre des mounts :
Si quelqu'un sait comment forcer le ssd à s'appeler sda, ça m'arrangerait.
Comment je vais aller expliquer ça au revendeur, moi ?
Alors les histoires de clés, on verra plus tard.
Et là je plie tout et je vais me balader
Dernière modification par jpt (11-10-2020 10:20:11)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
tu peux gérer les noms des disques dans un conky , par exemple .
comme çà , tu affiches les noms , les nos de série , les types pour repérer plus facilement tes disques ...
Dernière modification par Debian Alain (11-10-2020 13:14:11)
Hors ligne
en plus, il s'agit d'un apu, non d'un cpu.
donc testing.
Euh,
Le terme accelerated processing unit ou APU (signifiant en anglais : unité de calcul accéléré) est, en architecture informatique, un terme générique pour désigner une unité spécialisée dans l'accélération matérielle que l'on ajoute en aide au processeur principal (le CPU).
Donc il y a les deux, à charge pour Debian de s'en dépatouiller.
Et sinon, oui, je suis en 5.7.10 backporté, ça devrait le faire, non ?
Enfin, ça le fait bien au niveau des consoles, mais c'est loin, très loin d'être au point pour une clé sur laquelle j'ai installé une DF10 d'il y a un mois. (on en reparlera).
pour les noms des disques (sda, sdb, et sdc), bien qu'ils soient standardisés, cela n'est pas fiable.
Tu m'en diras tant !
Et je l'apprends aujourd'hui, après 20 ans de Linux sans l'ombre d'un souci. Grand merci à toi.
si tu tiens à tout prix à repérer sda, sdb et sdc, sers-toi des uuid des disques et du fstab.
C'est pas que j'y tienne, c'est plutôt qu'il faut !
Bon, c'est mis en place, plus qu'à patienter 8 jours pour voir si ça se passe mieux !
Merci à toi, allez, je file.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Et sinon, oui, je suis en 5.7.10 backporté, ça devrait le faire, non ?
Enfin, ça le fait bien au niveau des consoles, mais c'est loin, très loin d'être au point pour une clé sur laquelle j'ai installé une DF10 d'il y a un mois. (on en reparlera).
tu as oublié tous les soucis que tu as eu avec debian stable ?
(d'où d'ailleurs , la nécessité de passer en backports)
que stable (ou DFL , c'est pareil) ne se lance pas sur ton système ne m'étonne pas du tout .
au fait , oui , pardon pour la confusion gpu / cpu / apu ...
pour moi , un apu possède un cpu et un gpu intégrés ensemble sur la mme puce .
voilà pourquoi je prends ton proco pour un apu .
Ce terme a également été repris par les commerciaux de l'AMD Fusion, puis par l'ensemble du monde x86 pour dénommer une seule puce regroupant à la fois le CPU, et un ou plusieurs APU (dans le sens général),
https://fr.wikipedia.org/wiki/Accelerat … le%20CPU).
Dernière modification par Debian Alain (11-10-2020 13:27:31)
Hors ligne
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Sauf erreur de ma part, le comportement que tu suggères est fourni par le paquet command-not-found.
Je viens de l'installer avec Synaptic, ensuite, dans une console j'ai tapé audacity (qu'il faudra bien que j'installe, un jour) et ça m'a retourné
alors que Synaptic le trouve tout de suite.
Il y a un truc particulier à faire ? Parce que
me répond
Aucune entrée de manuel pour command-not-found
et l'aide en LdC est plus que succincte.
Merci,
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
En ligne