J'ai eu aussi l'information par un collègue de travail qui m'a envoyé une capture écran sur laquelle le FAT32 est le choix par défaut. Les fichiers à récupérer ne devraient pas dépasser 4 Go je choisi donc ... FAT32 is the winner !
[w] warning missing firmware dans debian et dérivés (ubuntu etc)
-
Ce tuto décrit comment régler le problème du [w] warning missing firmware
Il y a apparemment un bug dans le noyau linux qui fait qu'on a ce message d'erreur dans debian (et sans doute systèmes dérivés) pour les récentes versions.Note : ce tuto ne s'adresse pas à des débutants !!!
// ce qui à priori ne change rien (mais je l'ai fait quand même !)
Ajouter dans /etc/apt/sources.list :
#ajout de non-free
deb http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free
deb http://deb.debian.org/debian buster-updates main contrib non-freeInstaller apt-file pour faciliter la recherche de fichier :
sudo apt install apt-fileMettre à jour apt-file :
sudo apt-file updateInstaller firmware-linux (liste des firmware non-free) :
sudo apt install firmware-linux
sudo apt update//ce qui nous dit les firmwares manquants (car à priori un bug dans la table des versions des firmwares dans initramfs)
sudo update-initramfs -u -k all//on peut vérifier que les firmwares sont bien ici pour le device i915 (ce n'est pas le cas pour moi, il en manque)
cd /lib/firmware/i915/
ls//on créer un dossier git dans /home
mkdir git//on télécharge les firmwares non free, il y en a bcp dans le dépôt git ci-dessous :
git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git git//on teste avec un fichier
cp /home/yannick/git/i915/rkl_dmc_ver2_02.bin /lib/firmware/i915/ -i
ça marche !! plus de message d'erreur pour celui-ci !//on copie tout le dossier i915
sudo cp /home/yannick/git/i915/. /lib/firmware/i915/
cool, toutes les erreurs liées à i915 ont disparu.//on regarde du côté de rtl_nic (un autre pilote manquant chez moi)
Il n'y a pas de dossier rtl_nic dans les firmwares !//on créer le dossier
sudo mkdir /lib/firmware/rtl_nic//on copie les fichiers realtech
sudo cp /home/yannick/git/rtl_nic/. /lib/firmware/rtl_nic///on vérifie en faisant un update de initramfs
//au passage, je constate, que le job se fait pour tous les noyaux
sudo update-initramfs -u -k all
ça marche, tout est ok, plus d'erreur warning (normal, tous les fichiers dont on a besoin sont là) !//sudo reboot
tout est ok
pfiew !!!! -
Cela veut dire que pour une installation de Debian sans les firmware nonfree l'installation par la suite du paquet firmware-linux-nonfree ne les installe pas même après l'ajout du dépôt non-free au fichier
/etc/apt/sources.list.Pas fan de toutes ces étapes manuelles n'est-il pas préférable après avoir ajouter le dépôt nonfree télécharger l'archive contenant tous les firmware nonfree, la décompresser et enfin installer les firmware voulus (au format .deb). Cela permet de profiter des scripts pre et post-install contenu dans les paquets .deb (comme la mise à jour de l'initramfs). Qu'en penses -tu ?
-
Je rencontre effectivement régulièrement ce genre de problème (avec la carte mère Intel de mon vieux Thinkpad), qui se règle toujours comme indiqué par la recette. Proprietary software... comme d'habitude. C'est un peu le sel de Debian, mais effectivement, cela peut être un obstacle pour les installations sur des machines/architectures mal supportées. Ces problèmes sont encore là pour longtemps : au moins la durée d'une hégémonie !
-
Qu’en est-t’il avec la dernière version de Debian, Bulleye (publiée en août 2021) ?
deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb http://security.debian.org/debian-security/ bullseye-security main contrib non-free
deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb http://deb.debian.org/debian/ bullseye-backports main contrib non-free -
La documentation Debian apporte des informations à propos des firmwares pouvant manqués.
Je ne vois toujours pas où se trouve le bug mis en avant par @yannick85.
-
@Olivier Il me semble que j'ai trouvé le bug dans la bug list du kernel linux, par contre, incapable de vous dire où (il me semble que j'avais fait une recherche avec un mélange de initramfs et de warning mélangé à du kernel !!!), c'était en début de semaine... (chargée pour moi).
Il se trouve que ce bug - apparemment - dans les avant-dernières versions du noyau n'est plus là dans les toutes dernières versions. Et à priori, je pense que bulleyes (et à fortiori les versions précédentes) n'utilise pas les dernières versions du noyau (une façon de faire chez Debian). -
@Breti Mon problème était avec Bulleye ainsi qu'avec les versions précédentes.
-
@Olivier Concernant une install avec des fichiers .deb, il est possible que ça fonctionne, je n'ai pas essayé, il faudrait regarder ce que le deb contient pour voir si ça répond à ma problématique. Je m'aperçois néanmoins que plus on maîtrise linux en mode "manuel", moins on est obligé de passer par des surcouches inutiles pour répondre à des problèmes "précis" (un peu comme la chir). Comme les frameworks qui mettent des surcouches mais parfois ne peuvent répondre à des problématiques fines. Pas si évident tout ça. Il n'a pas d'approche systématique malheureusement. Il faut parfois mettre les mains dans le cambouis.
-
@yannick85 a dit dans [w] warning missing firmware dans debian et dérivés (ubuntu etc) :
il faudrait regarder ce que le deb contient pour voir si ça répond à ma problématique.
Recherchons le microprogramme i915 dans les paquets debian de l'archive firmware.tar.gz citée précédemment.
Le paquet debian suivant contient les 2 archives data et control qui permettent de lister l'ensemble des fichiers nécessaires à l'installation du firmware i915 et le script shell exécuté après la copie des fichiers dans
/lib/firmware. L'opération se termine par la mise à jour de l'initramfs.
-
@Olivier Je vois que tu es parti fouiller bien loin dans les archives ! Au point de retrouver le script shell responsable de la mise à jour initramfs ! Je ne maîtrise pas encore ce sujet très flou pour moi (le chargement de linux est un sujet qui m'intéresse bcp mais est très complexe). En tous cas, je vais regarder tes infos dès que j'ai un peu de temps. Pour le moment, je suis sur Guix, passionnant (et complexe aussi, c'est là dessus que bossent certains de l'inria).
-
Citer l'INRIA me fait penser à un article lu aujourd'hui https://www.tecmint.com/linux-distributions-for-science/.
-
@Olivier Pour préciser, certains personnes de l'INRIA, utilisent Guix pour assurer une reproductibilité du système, ce qui est synonyme quelque part de "science".
https://connect.ed-diamond.com/GNU-Linux-Magazine/glmfhs-113/deploiements-reproductibles-dans-le-temps-avec-gnu-guix
Bonne nuit, je me couche !
