Installation firmware debian 11

Tags: #<Tag:0x00007fb986ee0d58>

Bonjour,
Je viens d’installer Bullseye sur un vieux portable.

Type: Laptop System: SAMSUNG product: 350V5C/351V5C/3540VC/3440VC 
v: P09ABE.012.CP serial: xxxxxxxxxxxxxx 
Mobo: SAMSUNG model: NP350V5C-S06FR v: BOARD REVISION 00 
serial: 123490EN400015 UEFI: American Megatrends v: P09ABE 
date: 07/04/2013 

C’était un Debian 10 au préallable. Mais vu que j’ai pas beaucoup de reglages, je me suis laissé aller à repartir sur du neuf.
Le neuf c’est propre… sauf que le firmware a disparu.
Du coup maintenant au demarrage, je subis une temporisation de 30 secondes à 5 minutes dans le pire des cas… sur le message

drm:radeon_pci_probe
error radeon kernel

allez dans wiki.debian.org/firmware
Gloabelement

août 23 13:56:01 debianSam pipewire[1147]: Failed to receive portal pid: or>
août 23 13:56:00 debianSam gdm-password][1122]: gkr-pam: unable to locate d>
août 23 13:55:47 debianSam pipewire[700]: Failed to receive portal pid: org>
août 23 13:55:46 debianSam kernel: r8169 0000:02:00.0: Unable to load firmw>
août 23 13:55:46 debianSam kernel: r8169 0000:02:00.0: firmware: failed to >
août 23 13:55:45 debianSam kernel: Bluetooth: Loading patch file failed
août 23 13:55:45 debianSam kernel: firmware_class: See https://wiki.debian.>
août 23 13:55:45 debianSam kernel: usb 1-1.2: firmware: failed to load ar3k>
août 23 13:55:44 debianSam kernel: ata3: reset failed, giving up
août 23 13:55:44 debianSam kernel: ata3: SRST failed (errno=-16)
août 23 13:55:44 debianSam kernel: ata3: SRST failed (errno=-16)
août 23 13:55:44 debianSam kernel: ata3: SRST failed (errno=-16)
août 23 13:55:44 debianSam kernel: ata3: SRST failed (errno=-16)
août 23 13:55:44 debianSam kernel: See https://wiki.debian.org/Firmware for>
août 23 13:55:44 debianSam kernel: [drm:radeon_pci_probe [radeon]] *ERROR* >

Une explication, un lien, une source ?? dites moi vers ou aller svp.
Cdt

En l’absence de l’indication de la carte graphique je suggère d’installer le paquet non free :
https://packages.debian.org/bullseye/firmware-amd-graphics
Cela suppose évidemment que le fichier /etc/apt/sources.list fasse référence aux paquets non libres :

deb http://deb.debian.org/debian/ bullseye main contrib non-free

merci pour la reponse.
Ce paquet est bien flaggé installé dans synaptic
et un cat sur sources.list renvoie bien la ligne deb http a l’identique
d’un autre cote avec dmesg je trouve ca

[    5.114266] mmc0: new ultra high speed SDR50 SDHC card at address aaaa
[    5.350812] ata2.01: failed to resume link (SControl 0)
[    5.362600] ata2.00: SATA link down (SStatus 4 SControl 30)
[    5.362618] ata2.01: SATA link down (SStatus 0 SControl 0)
[    8.918776] ata3: link is slow to respond, please be patient (ready=0)
[   13.478770] ata3: SRST failed (errno=-16)
[   18.990792] ata3: link is slow to respond, please be patient (ready=0)
[   23.490780] ata3: SRST failed (errno=-16)
[   29.002795] ata3: link is slow to respond, please be patient (ready=0)
[   58.522796] ata3: SRST failed (errno=-16)
[   63.554798] ata3: SRST failed (errno=-16)
[   63.566610] ata3: reset failed, giving up

qui d’ailleurs maintenant remplace le message du firmware au boot.
Est ce possible qu’un redemarrage est resolu le probleme initial en laissant place au probleme suivant d’ailleurs…
Du coup le ata3 c’est un probleme lié au disque ?
je suis un peu perdu
Mon disque est un ssd.

C’est un problème qui apparaît souvent dans les forums, une petite recherche Internet avec

dmesg ata3: SRST failed (errno=-16)

retourne un nombre impressionnant de discussions. C’est bien un problème de lecteur, mais pas forcément lié au disque lui-même :
https://forum.ubuntu-fr.org/viewtopic.php?id=1312361
Voir si le fichier fstab est bien construit, notamment en utilisant les UUID pour référencer les partitions :

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=acb8e6d0-7612-4022-b5f4-7e8cc6590ab8 /              ext4    defaults,noatime 0 1

En effet cela peut être lié au contrôleur SATA hôte, au connecteur, au câble, à l’alimentation… mais en aucun cas au contenu de /etc/fstab. La première question à se poser est : qu’est-ce qui est connecté à ce port SATA ?

Device Model:     SSD 256GB
Serial Number:    242181980725
LU WWN Device Id: 0 000000 000000000
Firmware Version: FW201219
User Capacity:    256 060 514 304 bytes [256 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Aug 24 13:52:00 2021 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Les recherches sur le net m’ont conduit vers une piste de clip a manipuler sur le disque… et sur l’edition du grub avec l’instruction "noirq debug pci … blablabla" apres GRUB_CMDLINE_Linux_DEFAULT
ca n’a rien changé… pour ne pas dire que ca parait encore plus long maintenant.

Et je redis que ce portable demarrait normalement avec la debian 10. Donc, meme si on ne peut exclure les coincidences, ca reste peu probable que le disque devienne defectueux juste sur la reinstallation d’ne nouvelle base.

bon, je fais un update apres avoir testé sur ce portable sans succes.
et puis j’ai un autre portable avec une debian 10…
donc je me dis, essayons.
donc je commence par faire l’update complet et bim je me retrouve avec des firmware failed direct. donc c’est pas un probleme de la 11 mais de la 10 a priori.
du coup, c’est bizarre. Pourquoi faire une maj bancale sur la 10 ?
ca sent le divorce :slight_smile:

Perso je vois deux stratégies :
1 tenter de trouver l’origine du problème, mais cela peut prendre du temps. Mes compétences sur l’architecture PC ne sont pas suffisantes pour t’aider.
2 se dire que Linux/Debian est moins sujet aux régressions que d’autres OS… Et si régression il y a elles sont généralement vite identifiées et corrigées. Donc si le PC fonctionnait bien sous Buster il est peu probable qu’il ne fonctionne pas sous Bullseye. Récupérer une image live avec les logiciels et firmwares non libres et tenter un boot sur le live. Si cela fonctionne installer à partir du live. Si cela ne fonctionne pas c’est un bug plus proche du hard ou une panne hard.

Est-tu certain que c’est le SSD qui est connecté à ce port ?
Tu peux récupérer tous les messages ata du noyau avec dmesg pour voir ce qui est détecté.

Concernant les firmwares manquants, il suffit d’installer les paquets de la section non-free correspondants : firmware-amd-graphics, firmware-realtek. Mais je doute que ça ait un rapport avec les erreurs ATA. De même je doute que des paramètres du noyau noirq debug ou pci influent sur ces erreurs.

le ssd n’a pas changé de position entre deux installations debian…
je vais tenter une reinstall complete sur le deuxieme portable… mais c’est pas sur qu’il reste ne debian du coup !

une image live avec firmware non libre ? cad ? y a des options dans ce sens au moment du telechargement ?? je vais aller checker ca .

alors ca ressemblerait a ca peut etre ?
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-dvd/firmware-11.0.0-amd64-DVD-1.iso

Ce n’est pas la question. Le but est de vérifier ce qui est connecté sur ce port.

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.0.0-live+nonfree/amd64/iso-hybrid/