Vous n'êtes pas identifié(e).
Il y a le groupe d'erreur [sdb] cache qui concerne un ddr externe LABEL="PHOTOS" monter sur (sauf erreur) usb3
Ainsi que la deuxième série d'erreurs concernant ACPI et iommu.
Je lis en possibilité d'upgrader le bios? Sans toutefois en voir (ou savoir) s'il y a un nouveau dans le support ??
https://www.medion.com/nl/service/produ … sPage=true
code "1001 9031" pour accéder au service en ligne.
J'espère que ceci peut aider à identifier.
Quels sont vos analyses / procédures pour remédier à cet excès de rouge.
Merci aux lecteurs et aux aidants.
Hors ligne
Hors ligne
pour iommu c'est un warning aussi
c'est pas une erreur , mais une information , débranche les disques ou clé usb tu ne l' aura plus
Hors ligne
Première tentative. Renseignement du DDR externe dans le fstab.
Le DDR est bien monté, erreur [sdd] toujours présente.
Je remet le fstab à son état d'origine.
Test du grub avec iommu=soft
GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=soft splash" (l'erreur iommu n'est plus renseignée, disque externe débranché)
C'est ici que ce place la correction du post précédent concernant le rédémarrage en mode acpi=off
Le démarrage ne passe en écran noir mode grub >> (cela s'est surement présenté en chipotant précédemment aux paramètres du bios).
Ce démarrage passe par un fond d'écran bleu et trois carrés, puis passe au noir avec possibilité de connection pour commandes : login root (ce qui permet de modifier le fichier /etc/default/grub et d'effectuer un update-grub puis un reboot :-)
Démarrage machine avec GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi=off"
Démarrage machine avec GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=off"
Démarrage machine avec GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi=off splash"
Les trois tests renvoient à la même boucle de connexion. L'écran bleu, carrés passe au noir pour une connexion en mode commande.
-> Retour case départ : GRUB_CMDLINE_LINUX_DEFAULT="quiet"
Résumé :
iommu=soft est fonctionnel
acpi=off n'est pas fonctionnel
En supplément, j'ai ouvert la carcasse, la connexion USB du DDR externe est renseignée par une étiquette USB-4. Quelques test de démarrages avec un DDR externe auto-alimenté par la prise USB.
Sur un port usb noir (type 2), aucun message d'erreur.
Sur le second port USB-4, l'ordinateur n'a pas terminé son processus d'arrêt. Watchdog ...qqchose ERROR usb 8-2: cmd cmplt err -71
Disque Seagate Expansion USB-3
lol
Hors ligne
Hors ligne
Retour complet de la commande.
Je vois la présentation d'un lien pour
J'en profite pour les autres disques
L'idée du disque Seagate Expansion auto-alimenté en /dev/sde me traverse, j'identifie l'emplacement, sudo blkid met du temps sur l'usb4 et est rapide sur l'usb2.
Les résultas sont identiques selon les types d'usb
Par contre. J'arrive à monter le disque quand il est connecté sur port usb noir. Mais pas quand le disque est connecté à l'usb bleu.
Message Plasma Dolphin
Une erreur est survenue en accédant à « DebianMarc ». Le système a répondu :Une erreur non spécifiée est intervenue: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Dernière modification par macisa (27-11-2020 19:26:05)
Hors ligne
Hors ligne
Hors ligne
Y'aurait-il y a comme un mélange quand les deux disques sont branché sur l'usb4 ?
J'ai ouvert la machine. Il y a bien deux câble distincts et deux connections sur la carte mère.
Du coup, je pense que j'ai fait l'installation sur le port usb4 de la face avant de la tour parce que c'est le plus haut. Avec le disque externe branché :-)
Dernière modification par macisa (27-11-2020 20:06:19)
Hors ligne
lancement :
lecture / affichage du résultat :
Dernière modification par Debian Alain (27-11-2020 20:18:44)
Hors ligne
Le journal err, qui depuis la configuration de Smartmontools rajoute quelques lignes.
Dernière modification par macisa (28-11-2020 03:11:31)
Hors ligne
- sdc (seagate externe) sur lequel figure des données (PLUS)
apparemment , ton boot est mal configuré .
mais je préfère que les anciens regardent et te répondent .
chez moi :
chez toi :
je m' interroge ?
peut être : -- réinstaller le grub uefi --
Dernière modification par Debian Alain (28-11-2020 08:35:08)
Hors ligne
auto-alimenté par la prise USB.
C'est un contre-sens. "Auto-alimenté" est précisément l'inverse d'alimenté par le bus USB.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par macisa (28-11-2020 20:58:21)
Hors ligne
Hors ligne
Le disque externe auto-alimenté l'est bien sûr par la connexion du câble à une source.
Quel câble ? Le câble USB ou un câble d'alimentation spécifique ?
Dans la spécification USB, "auto-alimenté" (self-powered) qualifie un périphérique USB dont la source d'alimentation principale n'est pas le port USB. Adaptateur secteur, batterie interne, panneau photovoltaïque, pile à combustible, éolienne, dynamo de vélo, patates avec des électrodes, tout ce que vous voulez mais pas le port USB. L'inverse est dit "bus-powered" (alimenté par le bus USB).
je pense que ton boot / grub est légèrement mal installé .
Qu'est-ce qui te fait penser cela, et surtout qu'est-ce qui te fait penser que ça a une influence ?
Il vaut mieux montrer que raconter.
Hors ligne
Ce démarrage passe par un fond d'écran bleu et trois carrés, puis passe au noir avec possibilité de connection pour commandes : login root (ce qui permet de modifier le fichier /etc/default/grub et d'effectuer un update-grub puis un reboot :-)
donc , je m'interroge .
à priori , grub ne fonctionne pas .
en plus (post #13) :
son disque (macisa) :
le mien :
a disparu de sa partition "fat 32" .
maintenant , je suis pas un expert , je soulève juste 1 ou 2 faits que j'ai du mal à comprendre .
n.b. : testé ceci sur une v.m. uefi : -- réinstaller le grub uefi -- pas de souci .
Dernière modification par Debian Alain (29-11-2020 13:13:30)
Hors ligne
à priori , grub ne fonctionne pas .
Qu'est-ce que te fait dire cela ? Le système démarre, donc GRUB fait son boulot.
Certes, le rapport montre qu'il y a à la fois un GRUB pour l'amorçage BIOS dans le MBR et un GRUB pour l'amorçage EFI avec secure boot dans la partition EFI et qu'il manque à ce dernier le fichier grub.cfg indiquant la position de /boot/grub. Si c'était gênant, l'amorçage s'arrêterait sur l'invite de GRUB. Mais ce n'est pas le cas, donc j'en déduis que c'est le GRUB pour BIOS qui est amorcé, et lui est bien complet (mais fragile en l'absence de partition BIOS boot dédiée).
Tout ça n'est pas parfait, mais n'a rien à voir avec les problèmes mentionnés.
Il vaut mieux montrer que raconter.
Hors ligne
J'ai tâtonné un peu tout ce qui se trouve dans le BIOS, sans résultat.
ACPI ne donne rien. Coté IO, c'est grisé rien à modifier.
La modification du Legacy en UEFI envoi le démarrage de la machine directement dans l'édition du GRUB.
Je crois volontiers que je mélange les pinceaux :-) Ce sont juste des interrogations.
Sur le simple fait qui dirais que ce n'est pas parce que le processeur est 64 bits que tout l'ensemble de la machine soit capable d'un traitement en 64 bits. Que du coté de Microsoft, il semble envisageable d'installer une version 64 bits qui inclue certaines partie en traitement 32 bits. Que peut-être coté Debian, il soit que du 32 est du 32 et du 64 du 64.
Peut-ête effectivement une approche du coté de la configuration du grub.conf ou je me suis intrigué du coté de "set root='hd0,gpt2'" qui pourrait rejoindre le coté journal erreur iommu ivhd0:
@raleur
GRUB pour BIOS qui est amorcé, et lui est bien complet (mais fragile en l'absence de partition BIOS boot dédiée).
Cela veut-il dire que une partition /boot aurait été la bienvenue
Dernière modification par macisa (30-11-2020 10:12:33)
Hors ligne
Dernière modification par Debian Alain (30-11-2020 11:55:09)
Hors ligne
Comme j'ai installé une carte graphique en pci (et supprimé firmware-amd-graphic), cela donne :
On peut en déduire que tout est une question de foutu drivers!
Pour la carte graphique :
kernel: iommu ivhd0: Event logged [INVALID_DEVICE_REQUEST device=00:00.1 pasid=0x00000 address=0x000000fdf8010020 flags=0x0a00]
Pour le DDR Externe :
kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through
kernel: sd 5:0:0:0: [sdc] No Caching mode page found
Puisque - >
smartd[2306]: http://knowledge.seagate.com/articles/e … Q/223651en
smartd[2306]: http://knowledge.seagate.com/articles/e … Q/207931en
smartd[2306]: see the following Seagate web pages:
smartd[2306]: Device: /dev/sdc [SAT], WARNING: A firmware update for this drive may be available,
Identification nouvelle carte graphique
Malheureusement, je ne trouve pas de firmware adéquat. Peut-être pas encore cherché correctement. Ou dois-je installer quelques paquets présentés? Voir tous?
J'ai essayé le paquet nvidi-detect qui me renvoi à nvidia-drivers. Mais cela ne change rien.
Quand à :
kernel: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - \_PR_.C000 (20180810/dspkginit-414)
Et bien on ne sait toujours pas ce que c'est.
Cela fait bien rire ( jaune ) ces histoires de firmware.
Hors ligne
pour tes logs , je ne vois pas , à proprement parler , d'erreur .
que donnent : ?
Hors ligne
Hors ligne
Hors ligne