Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Dernière modification par Anonyme-11 (02-10-2018 17:56:50)
Dernière modification par Beta-Pictoris (29-09-2018 13:57:32)
Hors ligne
Installer une debian ?
j'y ai pensé, mais je l'ai déjà fait passer sur 5 système minimum...
J'aimerai autant pouvoir lui laisser ce qu'il a en ce moment.
Sinon, commencer par tester le disque et la ram.
la ram, ca m'ettonnerait, elle est neuve.
Par contre, le hdd est issu d'un vieux pc portable qui a par conséquent, certainement bougé en fonctionnement.
je vais essayer ton liens.
Si ça n'a est pas concluant, je vais finir par le mettre sous Debian, faudra que je regarde les autres environnement de bureau, parce qu’il a tendance a tout foutre dessus... 
merci beaucoup!
pour la ram elle peut avoir un vice caché . (selon la quantité de mémoire vive utilisé , le boot peut être aléatoire ) (si il y en a deux les croiser voir si ça modifie l'arrivée du reboot )
pour le disque tu fait : (pour voir les disques sur la machine)
puis
pour ceci , le système prend bien en charge le matériel ?
la carte mère est récente pas plus d'un an (la même que pour la manipulation sur la RX550? ).
tu connais les commandes maintenant , un lspci pour commencer.
Dernière modification par anonyme (29-09-2018 15:13:40)
pour lspci, j'ai noter quelques différence avec le miens, mais je n'arrive pas encore a l’interpréter.
ça c'est pas bon
tu verra sur ta machine , la deuxième ligne en partant du haut , IOMMU est bien reconnu sur le tien et pas ici (par exemple)
quand tu vois en fin de ligne "device" et un "code (chiffre)" c'est pas bon
tu vois que lui a beaucoup de ligne avec "device" en fin de ligne
pour en revenir a IOMMU il devrait avoir quelque chose du genre (pris sur ma machine)
comme => [AMD] Family 17h (Models 00h-0fh) I/O Memory Management Unit au lieu de => [AMD] Device 1577
pour le disque demande a un "barbu" mais cela me semble correct
un membre qui te donne en clair le retour que tu a posté
ps: regarde si pas une version de Mint plus récente (faire une mise a jour peut etre )
je suis 100% debian , je pourrai pas t'aider sur un OS que je connais pas.
Dernière modification par anonyme (29-09-2018 18:25:31)
pour le disque demande a un "barbu" mais cela me semble correct
Le barbu répond qu'il y a un secteur illisible d'après la valeur brute de l'attribut suivant :
Curieusement, les logs SMART ne contiennent aucune erreur. Il serait sage de passer badblocks en lecture seule sur tout le disque pour en avoir le coeur net.
Il vaut mieux montrer que raconter.
Hors ligne
ps: la carte vidéo ne va pas être utilisée ? ou c'est a cause des freezes que tu est en ssh
je t'ai expliqué pour ta machine que la carte mère en AM4 a besoin d un OS récent pour bien fonctionner.
la réparation du disque sur une machine stable ce serait mieux . (éviter les freezes sur des accès disques pas très bon).
minimum mettre un noyau des backports plus récent que le 4.9 et regarder si le retour de lspci est un peu mieux
un disque endommagé peu provoquer un freeze de la machine.
tout ce que je peu dire tu a deux soucis , un disque abîmé et un matériel mal reconnu
nota: faire un dist-upgrade sur une machine qui peu a tout moment planté , pas rassurant non plus.
ps: un disque neuf et une installation de buster ça va résoudre ton problème . (je prend pas trop de risque ........ )
sur des arrêts non conforme tu peu avoir des pertes de données et même abîmer ton disque.
Bonjour
pourquoi tu dis pas de carte graphique ?
elle est reconnu sur ton lspci (une des rares choses bien reconnu)
Je dis ça parce qu’il n'y en a pas.
Enfin, il y a un APU dans le processeur, mais pas de carte graphique dédiée
ps: la carte vidéo ne va pas être utilisée ? ou c'est a cause des freezes que tu est en ssh
Le ssh, c'est parce que mon copain utilise son pc pour travailler.
Par conséquent, quand je dois jeter un œil, je passe par ssh pour ne pas le déranger.
Merci pour les réponses, je vais investir dans un Seagate et une barette de ram de 4go(cf autre discussion sur ma mémoire ram) du coup.
A la prochaine!
Dernière modification par Anonyme-11 (01-10-2018 08:57:52)
Je ne suis pas encore parvenu a faire un badblocks complet (...)
badblocks n'a pas trouvé d'erreur jusqu'a 51/100 du hdd.
Tu peux relancer badblocks pour qu'il commence à partir de 50% jusqu'à la fin.
Est ce que le hdd peut provoquer ce genre de problème?
Cela me semble peu probable.
As-tu examiné les logs dans /var/log (kern.log, syslog...) au moment des reboots pour voir s'il y avait quelque chose, des erreurs disque ?
mettre un noyau des backports plus récent que le 4.9 et regarder si le retour de lspci est un peu mieux
La version du noyau n'a rien à voir avec la sortie de lspci. lspci utilise sa propre base de données d'identifiants PCI, qui peut être mise à jour en ligne avec
(idem pour la base de données d'identifiants USB utilisée par lsusb, avec
L'identification par lspci ou lsusb ne préjuge pas de la prise en charge par le noyau et vice versa.
Le ssh, c'est parce que mon copain utilise son pc pour travailler.
Par conséquent, quand je dois jeter un œil, je passe par ssh pour ne pas le déranger.
Comment dire... lancer badblocks sur le disque sans déranger l'utilisateur, c'est optimiste !
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par anonyme (02-10-2018 15:05:15)
le retour de lspci se fout du noyau explique ?
Qu'y a-t-il à expliquer ? Ce n'est pas assez clair ?
lspci utilise seulement le fichier /usr/share/misc/pci.ids pour identifier textuellement les périphériques PCI à partir de leurs identifiants numériques. Ce fichier n'est pas exhaustif, il ne contient que ce que les volontaires y mettent au fur et a mesure.
Le noyau a sa propre liste de périphériques PCI pour lesquels il a un pilote.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par anonyme (02-10-2018 15:01:29)
Il vaut mieux montrer que raconter.
Hors ligne
Idéalement, il faudra soit tenter de les corriger ou les faire réallouer par le firmware du disque en écrivant dedans, ou les ajouter dans la liste de secteurs défectueux du système de fichiers qui les contient. Ceci après avoir identifié le fichier ou répertoire qui le contient.
D'accord, je vais faire une recherche la dessus.
modifié : (gardé que le principal )
Trop tard, je l'ai lu avant. Alors j'ai fait quelques tests.
Jusqu'à Jessie, lspci se base uniquement sur le fichier pci.ids(.gz). En son absence, lspci n'affiche plus les noms.
Avec Stretch, (et peut-être Buster mais je n'en ai pas) effectivement lspci arrive à afficher les noms même sans le fichier pci.ids. L'exécution avec strace m'apprend qu'il tente d'ouvrir d'autres fichiers, dont un certain /lib/udev/hwdb.bin dont je n'ai jamais entendu parler et qui ne figure pas dans la page de manuel. Un coup d'oeil à ce fichier binaire permet de voir qu'il contient aussi des identifiants PCI. Ce fichier n'appartient à aucun paquet, je ne sais pas d'où il vient. Peut-être généré à partir de fichiers présents dans /lib/udev/hwdb.d qui appartiennent pour la plupart à udev. Bref, si je renomme aussi ce fichier alors lspci n'affiche plus les noms.
et si j'ai rêvé , a chaque monté en version du noyau j'ai eu des améliorations sur le retour de lspci
Je crains que tu aies rêvé. Ou alors c'est encore une nouveauté de Buster. Une comparaison objective des sorties avec des versions différentes de noyau toutes choses égales par ailleurs s'impose pour confirmer ou infirmer l'influence du noyau.
Il vaut mieux montrer que raconter.
Hors ligne
)j'ai effacé le dossier /lib/udev/hwdb.d/ par erreur
Quand on fait des tests, ne pas effacer mais renommer ou déplacer. Ça permet de revenir en arrière.
avec une commande de systemd j'ai régénéré le hwdb.bin
Quelle est cette commande, pour ma culture personnelle ?
par contre je n'ai pas trouvé comment remettre en état le dossier /lib/udev/hwdb.d/
Comme je l'ai écrit les fichiers contenus dans ce répertoire appartiennent à des paquets, essentiellement udev. Il faudrait donc réinstaller ces paquets. Tu peux les trouver avec
Dernière modification par raleur (05-10-2018 09:51:14)
Il vaut mieux montrer que raconter.
Hors ligne
tous les liens en #107 ici => https://debian-facile.org/viewtopic.php … 25#p278725
( udev et systemd )
comme je suis sur que tu ne va pas voir en #107 je te met le descriptif ici
NAME
systemd-hwdb - hardware database management tool
SYNOPSIS
systemd-hwdb [options] update
systemd-hwdb [options] query modalias
DESCRIPTION
systemd-hwdb expects a command and command specific arguments. It manages the binary hardware database.
OPTIONS
--usr
Generate in /lib/udev instead of /etc/udev.
-r, --root=PATH
Alternate root path in the filesystem.
-h, --help
Print a short help text and exit.
systemd-hwdb [ options] update
Update the binary database.
systemd-hwdb [ options] query [MODALIAS]
Query database and print result.
Dernière modification par anonyme (06-10-2018 00:30:13)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par Anonyme-11 (08-10-2018 21:56:44)