La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: vivien le 10 septembre 2024 à 15:35:25
-
Inflation de la taille du noyau Linux et de ses pilotes
Il est loin l'époque où le noyau Linux et ses pilotes prenaient moins de 1 Mo.
Depuis des années, la taille double tous les 1 à 2 ans.
Par exemple, avec Ubuntu 24.04 le noyau et ses pilotes (le gros paquet linux-firmware) pèsent maintenant 675 Mo !
(https://lafibre.info/testdebit/ubuntu/202409_ubuntu_2404_taille_noyau_linux.webp)
Je ne sais pas s'il y a une solution possible.
En même temps, le très bon support matériel de Linux est aujourd'hui une force.
On peut acheter un PC de dernière génération et on sait que tous les périphériques vont fonctionner directement.
-
@vivien :
On peut compiler son noyau et ne sélectionner que les modules requis pour faire fonctionner sa machine. Ce n'est définitivement pas à la portée de tous.
Les Anciens qui utilisent Gentoo le font certainement. Peut-être aussi les développeurs Linux.
Il y avait aussi le livre de Greg Kroah-Hartman mais je trouve qu'il est devenu trop ancien. (http://www.kroah.com/lkn/)
-
Ca paraît plus granulaire sur fedora (mais je ne m'amuse pas non plus à enlever des packages)
$ sudo dnf list installed *firmware |wc -l
22
$ sudo dnf repoquery --qf "%{size} %{name}-%{version}" *firmware* |wc
Last metadata expiration check: 0:18:57 ago on Tue 10 Sep 2024 03:48:50 PM CEST.
87 174 3027
$ sudo dnf repoquery --qf "%{size} %{name}-%{version}" *firmware* |head
Last metadata expiration check: 0:19:11 ago on Tue 10 Sep 2024 03:48:50 PM CEST.
10044983 brcmfmac-firmware-20240312
10050097 brcmfmac-firmware-20240811
103794 r5u87x-firmware-0.2.0
104715 ivtv-firmware-20080701
1143586 cirrus-audio-firmware-20240312
1148248 cirrus-audio-firmware-20240811
1182829 crystalhd-firmware-3.10.0
12492 linux-firmware-vendor-20231219.1
12525700 mt7xxx-firmware-20240811
12602703 mt7xxx-firmware-20240312
-
On peut compiler son noyau et ne sélectionner que les modules requis pour faire fonctionner sa machine.
Oui, c'était nécessaire il y a de nombreuses années (il y a plus de 20 ans).
Cela me rappelle de vieux souvenirs...
J'y ai passé du temps.
-
Cela me rappelle de vieux souvenirs...
Et pour des souvenirs encore plus lointains, ça me rappelle l'époque où j'installais des "UNIX" sur PC-AT avec un jeu de disquette 5" 1/4. On "croisait" les doigts au moment du reboot, après avoir installé une vingtaine de disquettes. Parfois, ça ne démarrait pas ...
A l'époque, c'était évidemment sur architecture 16 bits, noyau monolithique, mais il était assez facile d'écrire des drivers et de recompiler le noyau. On le faisait pour des cartes d'interface (multiport RS 232), des disques durs, etc ou tout simplement pour changer des paramètres du noyau (pas de sysctl)
-
Et pour des souvenirs encore plus lointains, ça me rappelle l'époque où j'installais des "UNIX" sur PC-AT avec un jeu de disquette 5" 1/4. On "croisait" les doigts au moment du reboot, après avoir installé une vingtaine de disquettes. Parfois, ça ne démarrait pas ...
A l'époque, c'était évidemment sur architecture 16 bits, noyau monolithique, mais il était assez facile d'écrire des drivers et de recompiler le noyau. On le faisait pour des cartes d'interface (multiport RS 232), des disques durs, etc ou tout simplement pour changer des paramètres du noyau (pas de sysctl)
Il y a eu des Unix en 16 bits sur x86? Sur PC-AT 286? Je ne savais pas.
C'était quoi comme Unix, stp? Tu te souviens? Ca m'intéresse.
Tous les Unix que je connais sont en 32 bits ou 64 bits. Donc 386 au pire.
Leon.
-
Il y a eu des Unix en 16 bits sur x86? Sur PC-AT 286? Je ne savais pas.
C'était quoi comme Unix, stp? Tu te souviens? Ca m'intéresse.
Tous les Unix que je connais sont en 32 bits ou 64 bits. Donc 386 au pire.
C'est que je suis encore plus vieux que toi ... mais je me souviens, la sénilité ne m'a pas gagné.
En 1986, j'ai commencé à travailler dans le cadre de mon service national sur un système Unix sur PC (Goupil G40), donc sur processeur 80286.
On était 3 "scientifiques du contingent" à développer en Pascal, qui était en fait un traducteur Pascal - C sur cette machine.
On s'y connectait avec des terminaux (type VT) branchés en série sur ligne RS 232.
A cette époque, l'espace adressable par un programme était 64 kO, ce qui nous posait quelques difficultés (même pour des programmes en "curses").
J'ai ensuite, en 1987, rejoint la société qui importait en France cet OS fabriqué par la société VenturCom. Le produit s'appelait Venix. Le concurrent principal était Xenix distribué par SCO.
Peu de temps après sont apparues des versions 32 bits effectivement (un concurrent connu : Interactive Systems 386 ix).
(et pour finir sur ce rappel historique : dès 1987, la société dans laquelle je travaillais importait des "packages TCP/IP" pour apporter des couches "réseau" sur des OS qui n'en disposaient pas en standard, comme les VAX VMS de DEC. Le câblage se faisait en Thick Ethernet).
J'arrête ici pour mes histoires de vétéran ...
-
Oui, c'était nécessaire il y a de nombreuses années (il y a plus de 20 ans).
Cela me rappelle de vieux souvenirs...
J'y ai passé du temps.
Pour ma part, l'intérêt de l'exercice s'était renouvelé avec la possibilité des noyaux EFI STUB.
Beau souvenir que le premier boot direct sur un kernel monolithique aux oignons. Derrière un clavier, l'épure est la seule quête qui vaille ! ;D
-
Compiler soi-même son noyau, c'est généralement ne plus y toucher de nombreux mois, et donc ne pas corriger les failles de sécurité, non ?
-
Compiler soi-même son noyau, c'est généralement ne plus y toucher de nombreux mois, et donc ne pas corriger les failles de sécurité, non ?
Un script de mise à jour est facile à mettre en place. Et puis limiter les options, c'est aussi théoriquement limiter les possibilités de bugs et donc de failles non ?
J'ai toujours considéré le noyau comme un logiciel comme un autre pour les mises à jour : paradoxalement, mettre à jour souvent limite la casse. Rien de pire que de sauter 5 versions majeures et de bâcler la mise à jour.
Entre une config standard de debian avec 6k lignes dans le .config et une config custom 1-2k lignes, le choix est vite fait.
-
Bonjour,
Est-ce que cette taille de noyau grandissante pourrait finir par être un problème vu l'évolution des capacités des SSD ? Mon 1er portable avec un SSD avait une capacité de 120Go. Maintenant 256 ou 512 semble être la norme.
Comme indiqué dans le 1er post, si cela permet d'avoir la quasi assurance que tout fonctionne "out of the box" c'est quand même sympa.
Même si bien sûr cela ne met pas à l'abri des erreurs ou bug. J'ai le cas sur ma machine actuelle : Le driver nécessaire à la gestion de l'écran est absent des dernières versions. Ceci depuis au moins 6.2 de mémoire. Donc ma config est plus fonctionnelle avec le kernel GA de Ubuntu 22.04 plus ancien mais plus petit en taille. Et cela me "bloque" sur cette version.
Est-ce qu'il est imaginable, dans le futur, qu'avant l'installation la machine soit "évaluée" par le programme d'installation lors de la session live pour ne télécharger/installer que le nécessaire ? Avec les capacité disques et les connexions fibres, je suis pas certain que l’intérêt soit énorme pour les particulier en tout cas.
Bonne journée
-
Le noyau compilé ne prends pas beaucoup de place. C'est l'ensemble des firmwares le problème. Mais il est possible d'avoir une gestion plus fine. C'est le cas de certaines distributions. Après, il suffit de pas prendre le paquet et de chercher manuellement les quelques fichiers nécessaires. A part les microcodes de processeurs qui ont des paquets à part, les mises à jours ne sont pas courantes non plus.
-
Ça bouge quand même régulièrement https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/ (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/)
C'est aussi pour ça que garder un noyaux fourni avec la distribution qui fourni aussi les firmware c'est quand même préférable hors cas très spécifique.
-
A part les microcodes de processeurs qui ont des paquets à part, les mises à jours ne sont pas courantes non plus.
14 jours plus tard, on passe de la version 2.3 à la version 2.4, avec de nouveau 484 Mo de firmware à télécharger sur tous les postes (la taille a augmenté de 500 Ko).
(https://lafibre.info/testdebit/ubuntu/202409_ubuntu_2404_taille_noyau_linux_2.webp)
-
Cela mériterait quand même une gestion plus fine franchement.
Ubuntu n'a pas un système de delta entre les versions de paquets comme opensuse ? (EDIT : oups https://fedoraproject.org/wiki/Changes/Drop_Delta_RPMs)
-
j'ai du mal a voir en quoi c'est un probleme
500Mo ou 2go franchement, osef non ? Ou ca change quelque chose pour quelqu'un ?
-
Les mises à jour représentent un poids non négligeable.
Imagine que tu as 500 postes, cela fait du volume.
C'est également le cas de Windows.
Je viens de changer de PC préinstallé Windows 11 (il va bientôt passer sous Ubuntu), j'ai regardé : Le démarrage et les mises à jour de toutes les applications ont pris 10 Go sur ma connexion.
-
d'où ma question : qu'est ce que ca change ?
J'ai aussi quelques dizaines de linux en prod et la consommation de bande passante pour telecharger les mise a jour...... heu, comment te dire que c'est le dernier de mes soucis ?
qu'on me reponde "moi je dors mieux la nuit si le kernel fait 10mo de moins", ok je peux comprendre, mais a part ca ?
-
Les aficionados du logiciel libre ont souvent fait référence aux blobs propriétaires (notamment les micrologiciels, alias firmwares) dans leur système d'exploitation.
En fait, c'est assez drôle en y pensant, car blob signifie « objet binaire large » (binary large object).
-
Le support des pilotes des périphériques sous Windows est assuré par le fabriquant. Une fois le matériel en fin de vie, le support finit par ne plus être assuré. Il peut y avoir des traces sur le net, mais on finit un jour par devoir croiser les doigts pour espérer faire fonctionner un périphérique sur un Windows récent. Je pense par exemple à certains périphériques à longue durée de vie sur Windows serveur. Je ne peux manquer de sourire en écrivant ces 2 mots collés l'un à l'autre, mais nombreuses sont les sociétés prisonnières (in)volontaires de cet écosystème toxique.
Sous linux, par contre, les pilotes disposent de sources, dans la très très grande majorité des cas. Il se peut que, parfois, pour pouvoir utiliser un équipement aux performances particulièrement brillantes, suivez mon regard sur la carte vidéo RTX de nos rêves, on sacrifie au rite pour compiler un très très gros binaire propriétaire linké dans un pseudo pilote interface aux sources ouvertes. Dans la très grande majorité des cas, les pilotes sont open source, et peuvent se compiler depuis un noyau vétuste jusqu'aux plus récents.
Le noyau linux, qui embarque les sources de tous ces pilotes de périphériques, et dieu sait qu'ils sont nombreux, voit donc sa taille enfler sans arrêt.
Les firmware, qui sont des pilotes de plus bas niveau injectés par le pilote noyau dans le périphérique pour en assurer le démarrage et le fonctionnement, voilà encore un blob propriétaire. Plus les périphériques sont nombreux, plus on compte de firmware. Un firmware de périphérique entre dans le noyau pour, pour ainsi dire, n'en plus jamais sortir.
Je ne trouve absolument pas hors de propos de compiler son noyau, même sur une Debian. Nombreux sont les outils qui permettent de le faire de façon remarquablement automatique. La gymnastique consiste fondamentalement à garder une vision globale des différents composants du noyau, et à, une fois l'effort de compiler une fois un noyau adapté à une configuration matérielle donnée, lire attentivement les indications d'aide d'un "make oldconfig" pour évaluer rapidement si la nouveauté mérite d'être intégrée ou pas.
Pour ma modeste part, tant que je ne vole pas sur MSFS, je reste sous linux, distribution Gentoo, avec un noyau très récent, compilé en statique sauf le pilote nvidia.
J'ai eu jusqu'à récemment des bases de données relativement volumineuses et à trafic soutenu, sur un système Debian auquel j'avais ajouté un noyau minimaliste aux options sélectionnées à la main. Les performances s'en ressentaient.
La compilation du noyau Linux de sa station, il ne faut pas en avoir peur. Une machine récente 16C/32T boucle l'affaire en moins de 1'30''.
Si on a pas fait ça depuis très longtemps, au début, ça pique, mais pour aider à produire une configuration utilisant juste les pilotes adaptés à une configuration matérielle, sans support des chargement de module dynamique, des pistes sont prévues dans le noyau standard.
Prenez une machine linux, lancée, téléchargez les sources du noyau identique au noyau actif, branchez tous vos périphériques, tous, et rendez vous à
#cd /usr/src/linux
Lancez un
# lsmod > /tmp/mylsmod
# make LSMOD=/tmp/mylsmod localmodconfig
# make localmodconfig
Cette option :
- Analyse les modules actuellement chargés sur le système (via la commande lsmod).
- Crée une nouvelle configuration du noyau qui n'active que les options nécessaires pour ces modules chargés.
- Désactive toutes les options de modules qui ne sont pas nécessaires pour les modules actuellement chargés.
- Conserve les paramètres des modules (compilés en tant que modules ou intégrés) tels qu'ils sont dans la configuration actuelle.
L'objectif principal est de créer une configuration minimale du noyau adaptée au matériel et aux fonctionnalités actuellement utilisés sur le système.
Déjà, avec ça, on a juste le nécessaire.
On peut pousser plus loin:
# make localyesconfig
Cette option fonctionne de manière similaire à localmodconfig, mais avec une différence clé :
- Elle configure tous les modules actuellement chargés pour être compilés directement dans le noyau (built-in) plutôt que comme modules chargeables.
- Cela peut permettre de se passer d'un initramfs dans certains cas
Là, on a juste géré ses pilotes de périphériques. On peut choisir spécifiquement de nombreuses options dans d'autres parties, comme:
- Options générales
- Configuration générale du système - Osons rentrer dedans
- Support des architectures matérielles - générer un binaire non générique, plus adapté à son processeur top sexy
- Options de débogage et de profilage - parfois utiles quand ça plante. On remonte un bug upstream
- Gestion du matériel
- Pilotes de périphériques (disques, cartes réseau, cartes graphiques, etc.)
- Support des bus et interfaces (PCI, USB, SCSI, etc.) - ATA, souvent encore présent, SCSI, à évincer
- Gestion de l'énergie (ACPI, APM) - Indispensable sur un laptop, éventuellement une station, moins utiles sur un serveur à charge constante
- Systèmes de fichiers
- Systèmes de fichiers natifs (ext4, XFS, Btrfs, etc.) - Autant j'en mets un paquet sur mon laptop qui sert de couteau suisse, autant on peut se passer de reiserfs ou d'autres
- Systèmes de fichiers réseau (NFS, CIFS, etc.) - idem
- Systèmes de fichiers virtuels (procfs, sysfs) - attention avec ceux là
- Réseau
- Protocoles réseau (IPv4, IPv6, etc.)
- Pare-feu et filtrage de paquets (Netfilter)
- Support des technologies réseau sans fil - désactivé sur ma station connectée en 10Gbps, par exemple
- Sécurité
- Contrôle d'accès (SELinux, AppArmor) - vade retro la NSA. En aucun cas je ne prête la moindre confiance dans le moindre bout de code fournit par eux. Déjà qu'ils ont la Trusted Platform...
- Chiffrement et cryptographie - beaucoup moins inutile qu'on ne pense.
- Audit de sécurité - diminuer l'exposition aux attaques par canaux auxiliaires, durcissement de pile, etc
- Virtualisation et conteneurisation
- Support des hyperviseurs (KVM, Xen)
- Conteneurisation (cgroups, namespaces)
- Multimédia et son
- Pilotes audio
- Support des codecs et frameworks multimédias
- Optimisation des performances
- Ordonnanceurs CPU et I/O - haaa, l'ordonnanceur Brain Fuck Scheduler de Con Kolivas (https://ck-hack.blogspot.com/)...
- Gestion de la mémoire et du swap
Bref, il n'y a que du bon à gratter à compiler son noyau Linux.
Il faut se lancer.
-
Ubuntu 24.10 passe la barre des 500 Mo : (c'est le noyau Linux 6.11 qui est utilisé)
(https://lafibre.info/testdebit/ubuntu/202411_ubuntu_2410_taille_noyau_linux_6-11.webp)
-
Ubuntu 24.10 passe la barre des 500 Mo : (c'est le noyau Linux 6.11 qui est utilisé)
Ce sont tous les firmware bouts à bouts, de tous les périphériques en ayant besoin, qui pèsent 500Mo, dans ce cas.
Dans tous les cas, vu que les sources du noyau contiennent les sources des pilotes eux mêmes, la tendance va légitimement vers l'inflation.
Fondamentalement, la somme des firmware de périphériques divers augmente plus vite que les sources même du noyau.
Pour Gentoo
# emerge -pv sys-kernel/linux-firmware sys-kernel/gentoo-sources
These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 3.08 s (backtrack: 0/20).
[ebuild U ] sys-kernel/linux-firmware-20241110::gentoo 396 088 KiB
[ebuild NS ] sys-kernel/gentoo-sources-6.12.1:6.12.1::gentoo 144 451 KiB
Total: 2 packages (1 upgrade, 1 in new slot), Size of downloads: 540 539 KiB
Si l'on prend le dernier kernel disponible sur kernel.org, le 6.12.1 à cette heure, le tarballen .xz pèse 147,9Mo, et l'archive dépliée atteint 1.5Go
-
A part les microcodes de processeurs qui ont des paquets à part, les mises à jours ne sont pas courantes non plus.
Décembre 2024
(https://lafibre.info/testdebit/ubuntu/202412_ubuntu_2410_taille_noyau_linux_6-11.webp)
Janvier 2025
(https://lafibre.info/testdebit/ubuntu/202501_ubuntu_2410_taille_noyau_linux_6-11.webp)
Mars 2025
(https://lafibre.info/testdebit/ubuntu/202503_ubuntu_2410_taille_noyau_linux_6-11.webp)
Avril 2025
(https://lafibre.info/testdebit/ubuntu/202504_ubuntu_2410_taille_noyau_linux_6-11.webp)
-
Vivien,
Pourquoi mettre cette citation à chaque fois ? ...
Forcément, avec le grand nombre de firmwares, il y a de quoi faire des mises à jour tous les mois.
Mais si tu prends un système donné, il y a peu de mises à jour par composant.
Par exemple pour cirrus, qui apparait souvent dans tes screenshots. Si on sélectionne un firmware et qu'on regarde les logs :
path: root/cirrus/cs35l41-dsp1-spk-cali-103c896e-l0.bin
Age Commit message (Expand) Author Files Lines
2024-04-23 linux-firmware: Remove Calibration Firmware and Tuning for CS35L41 Stefan Binding 1 -0/+0
2022-10-14 linux-firmware: Add firmware for Cirrus CS35L41 on HP Laptops Stefan Binding 1 -0/+0
Tu prends un firmware ath9k/ath10k, même chose, une mise à jour par an max.
-
Le système n'est pas bien fait pour la mise à jour de quelques centaines Ko de drivers, on doit mettre à jour chaque mois (ou presque) un fichier de plus de 500 Mo.
-
Bonjour connaissez vous GNU Hurd, la collection de serveurs qui utilise le micronoyau Mach ?
-
Debian GNU/Hurd reste un système expérimental, dont la stabilité et les performances sont loin de celles de Debian GNU/Linux.
Il y a également les BSD en alternative, mais cela a un impact fort sur la compatibilité matérielle et la simplicité.
-
GNU Hurd, combien de divisions ? Je ne connais personne qui l'utilise.
Le noyau monolithique de Linux a au moins un mérite, c'est que tout est sous licences GPL v2. Avec un micronoyau, il pourrait y a voir des modules sous différentes licences. Je n'imagine même pas les problèmes de licences incompatibles, ou demandant d'utiliser tel module sous telles conditions.
A côté des options techniques, on oublie trop souvent le problème des licences.
-
Bonjour connaissez vous GNU Hurd, la collection de serveurs qui utilise le micronoyau Mach ?
Haiku, le système héritier de la lignée BeOS, par jean louis gassée, ancien président d'apple france qui avait tenté de faire virer steve jobs dans les années 80, est certainement plus utilisé que hurd, qui tire dans ses racines le noyau Mach d'Avie Tevanian, qui est à la base, avec des ptits bouts de freebsd, de darwin, le système dans macos/ios.
On pourrait se demander quel OS grand public pourrait utiliser hurd aujourd'hui : à part des chercheurs par ci par là, je crois que juste personne connait. Même plan9 est davantage utilisé que hurd ;)
-
On sait aussi sous Linux les difficultés à mettre à jour le noyau quand un module est externe est inclus, en particulier un driver blob de carte graphique. Donc si tous les drivers étaient comme cela, j'aurais les plus grosses craintes.
-
Bonjour,
Peut-être un premier pas vers une (légère) réduction de la taille des noyaux avec l'arrêt du support des anciens matériels : https://macbidouille.com/news/2025/05/11/le-kernel-linux-va-abandonner-le-486
Bonne journée
-
Il y aura du nouveau avec la prochaine version LTS d'ubuntu :
https://www.omgubuntu.co.uk/2026/02/ubuntu-26-04-firmware-split (https://www.omgubuntu.co.uk/2026/02/ubuntu-26-04-firmware-split)
Traduit avec Claude :
# Ubuntu 26.04 divise le paquet de micrologiciels pour simplifier les mises à jour
**Ubuntu 26.04 LTS (Resolute Raccoon) modifie la manière dont les mises à jour de support matériel sont gérées, en divisant son unique paquet `linux-firmware` en 17 sous-paquets spécifiques aux fournisseurs.**
Cette nouvelle approche vise à réduire la taille des mises à jour de micrologiciels pour la plupart des utilisateurs. Actuellement, les fichiers de micrologiciels sont contenus dans un seul paquet dont la taille de téléchargement dépasse 500 Mo dans les versions récentes (et utilise jusqu'à 1 Go d'espace disque une fois installé).
Par conséquent, même si un correctif de sécurité est appliqué à du matériel spécialisé comme une mise à jour de 100 Ko pour les cartes réseau Netronome ou Mellanox, principalement utilisées dans les centres de données d'entreprise, tous les utilisateurs d'Ubuntu doivent télécharger l'intégralité de la mise à jour `linux-firmware` – plus de 600 Mo dans Questing.
L'ingénieur de Canonical Juerg Haefliger note que les mises à jour de sécurité des micrologiciels arrivent dans le dépôt `-security` qui, pour des raisons d'hygiène de sécurité, n'est pas mis en miroir, ce qui signifie que "le monde entier accède à un seul serveur en même temps".
Les mises à jour volumineuses de fichiers de micrologiciels gaspillent de la bande passante et exercent une pression inutile sur l'infrastructure d'Ubuntu.
Les développeurs de la distribution ont discuté de moyens de réduire la taille des mises à jour de micrologiciels l'année dernière et maintenant, dans Ubuntu 26.04, ils introduisent un système de méta-paquets pour répartir les micrologiciels Linux sur 17 sous-paquets dans les archives `resolute` – résolvant ainsi un bug signalé en 2022.
Les sous-paquets sont :
* linux-firmware-mellanox-spectrum
* linux-firmware-intel-wireless
* linux-firmware-intel-graphics
* linux-firmware-amd-graphics
* linux-firmware-nvidia-graphics
* linux-firmware-intel-misc
* linux-firmware-broadcom-wireless
* linux-firmware-netronome
* linux-firmware-misc
* linux-firmware-qlogic
* linux-firmware-marvell-wireless
* linux-firmware-mediatek
* linux-firmware-marvell-prestera
* linux-firmware-realtek
* linux-firmware-qualcomm-wireless
* linux-firmware-qualcomm-graphics
* linux-firmware-qualcomm-misc
La plupart de ces paquets resteront installés par défaut pour garantir qu'Ubuntu 26.04 LTS fonctionne avec une large gamme de matériels.
La différence est que lorsque des mises à jour de micrologiciels seront publiées, seuls les paquets contenant des micrologiciels modifiés devront être téléchargés. Si, par exemple, une faute de frappe est corrigée dans les pilotes Intel Wireless, seul ce paquet installé récupérera la mise à jour.
Tous les paquets restent regroupés sous l'égide de `linux-firmware`.
Ce changement est actuellement en cours de déploiement et, à condition qu'aucun problème majeur ne soit détecté avec cette nouvelle approche, il sera en place lors de la sortie d'Ubuntu 26.04 LTS en avril 2026.
-
L'ingénieur de Canonical Juerg Haefliger note que les mises à jour de sécurité des micrologiciels arrivent dans le dépôt `-security` qui, pour des raisons d'hygiène de sécurité, n'est pas mis en miroir, ce qui signifie que "le monde entier accède à un seul serveur en même temps".
Ce n'est pas tout à fait vrai : Les utilisateurs français on normalement un /etc/apt/sources.list.d/ubuntu.sources de ce type (en configuration par défaut, si la localisation "France Paris" est sélectionnée lors de l'installation) :
Types: deb
URIs: http://fr.archive.ubuntu.com/
Suites: questing questing-updates questing-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: questing-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
Le dépôt `-security`est présent en double : sur le miroir local et sur security.ubuntu.com
Si le miroir local a les paquets à jour pour la sécurité, c'est sur ce dernier qu'ils sont téléchargés.
Le téléchargement sur security.ubuntu.com se fait en cas de miroir défectueux ou non à jour.
Pour fr.archive.ubuntu.com, je fais une synchronisation toutes les 2 heures (c'est visible sur https://fr.archive.ubuntu.com/log/ ), les cas où les téléchargements se font sur security.ubuntu.com sont rares (et je vois bien passer ces mises à jour mensuelles des Micrologiciels, cela fait des pics de trafics importants).
En tout cas, c'est une bonne chose de scinder ce gros paquet.
-
Salut à tous les experts Linux.
J'avoue que j'ai beaucoup de mal à comprendre la situation.
Pourquoi le noyau Linux doit contenir TOUS les drivers et firmware, de tous les matériels ?
C'est aberrant, non?
Une machine donnée ne va utiliser que quelques pourcent de tout ça, selon le matériel réel qu'elle a.
Ne serait-il pas plus judicieux de faire des installations minimalistes avec le strict nécessaires, puis de télécharger les drivers et firmware à la demande, selon le matériel de l'utilisateur? J'ai l'impression que c'est ce que fait Windows: après une installation Windows, il manque souvent des drivers spécifiques, qui sont installés à postériori.
Pour revenir à Linux, j'ai récemment installé Ubuntu-server (minimaliste, sans interface graphique, sans application) sur des petites machines de récup (Dell Wyse 3040), et constaté qu'en disque dur, ça bouffait quasi 4Go (sur les 7Go disponibles sur ces machines). Je trouve ça énorme pour un OS de base sans rien.
Leon.
-
Avec Linux, il est possible d'installer le système sur une clé USB ou un disque dur USB et passer de PC en PC.
J'ai tenté la même chose avec Windows, j'ai un écran bleu au boot quand je change de PC.
Si plusieurs distributions se basent sur Ubuntu et non Debian, c'est souvent pour bénéficier des nombreux firmwares qu'il possède. Ubuntu es connue pour supporter plus de matériels exotiques que d'autres distributions. Le matériel récent est rajouté au fur et à mesure dans les mises à jour mises à jour mensuelles des Micrologiciels.
Aujourd'hui avec un matériel extrêmement récent, l'ordre s'est inversé : c'est plus simple avec Linux qu'avec Windows.
Oui, il se pose une question de quand retirer le matériel obsolète.
Par exemple, les cartes SCCI Adaptec sont encore pleinement supportées par Ubuntu 25.10 (je l'ai installé sur un vieux Pentium 4 avec carte SCSI).
Ubuntu n'est pas forcément la distribution la plus adaptée si tu as très peu d'espace disque. Ubuntu vise une haute compatibilité et les performances (d'où la mise en place de paquets binaires optimisés pour l'architecture x86-64-v3 (aussi appelée amd64v3 chez Ubuntu).
Il y aura peut-être deux ISO pour Ubuntu 26.04 : AMD64 à partir du Pentium 4 et AMD64v3 pour bénéficier des instructions des processeurs récents (date de lancement postérieur à 2013, cf page Wikipedia (https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels)).
On voit de plus en plus de comparaitf, ou avec certaines configurations (GPU AMD) les jeux Windows tournement plus rapidement sous Linux que Windows. On voit de plus en plus de gamer se tourner vers Linux (merci Steam).
À noter qu'il est possible d'avoir un Linux sur 1,4 Mo : Cf An Embedded 🐧Linux on a Single 💾Floppy 2025 Edition (https://krzysztofjankowski.com/floppinux/floppinux-2025.html)
Pour ton besoin Leon, tu devrais tenter Debian 13.
-
Par conséquent, même si un correctif de sécurité est appliqué à du matériel spécialisé comme une mise à jour de 100 Ko pour les cartes réseau Netronome ou Mellanox, principalement utilisées dans les centres de données d'entreprise, tous les utilisateurs d'Ubuntu doivent télécharger l'intégralité de la mise à jour `linux-firmware` – plus de 600 Mo dans Questing
vraiment ? :o
je n'ai pas souvenir de ce comportement.
quand j'utilisais Ubuntu je squattais un hotspot dans le quartier
je pense que j'aurais souvenir de mises à jour si lourdes...
en tous les cas sur Debian (la base d'Ubuntu) il ne télécharge que les fichiers à mettre à jour...
des fois je ne télécharge que 100ko par mise à jour
constaté qu'en disque dur, ça bouffait quasi 4Go (sur les 7Go disponibles sur ces machines). Je trouve ça énorme pour un OS de base sans rien
ah oui sur de très vieilles machines comme cela il faudra voir une distro spéciale
en tous cas pas Debian ni Ubuntu
-
Salut à tous les experts Linux.
J'avoue que j'ai beaucoup de mal à comprendre la situation.
Pourquoi le noyau Linux doit contenir TOUS les drivers et firmware, de tous les matériels ?
C'est aberrant, non?
Une machine donnée ne va utiliser que quelques pourcent de tout ça, selon le matériel réel qu'elle a.
Parce que Linux, contrairement à Windows, ne garantit aucune stabilité de son ABI (https://fr.wikipedia.org/wiki/Application_binary_interface). Si un pilote est laissé en dehors du noyau, il devient incompatible très vite et se casse à la prochaine màj du noyau. En étant intégré aux mêmes dépôts de code source que le noyau, ça permet de s'assurer que les màj du noyau ne vont rien casser.
Windows a fait le contraire : ABI figée, mais par conséquent contrôle qualité fragmenté dans tous les sens, et gestion de la sécurité de l'anneau 0 (ring0) du noyau qui est de facto déléguée aux équipementiers et leur code souvent calamiteux
(Dites-moi si j'ai fait une erreur de compréhension car ça fait un bail que j'ai regardé ces détails techniques)
-
le noyau n'est pas le problème
il pèse moins de 20Mo
après il y'a les modules (pilotes...) et l’initrd (boot...)
mais ça ne dépasse pas 300Mo
le reste c'est l'interface graphique éventuelle, les programmes (et leurs dépendances)...
"""
pour une installation standard de Debian =>
Système de base + outils usuels : 3 à 4 Go
Environnement + applications graphiques (éditeur, terminal, navigateur, visionneuse, etc.) : 2 à 3 Go
Total après installation (sans données perso) : en pratique environ 6 à 8 Go sur le disque.
avec quelques logiciels en plus (LibreOffice, quelques navigateurs, etc.) => vers 8 à 10 Go
"""
___________________________
edit :
je viens de faire une mise à jour (Debian 13)
je ne prends que ce qui est nécessaire
ici 81MB
je ne comprends pas pourquoi Ubuntu irait tout télécharger à chaque fois ?
-
Si, la taille du noyau peut être un problème.
Mon exemple : j'ai installé mon PC sous arch il y a 8 ans. Mon /boot fait 381MB, ce qui était très largement suffisant à l'époque et a été suffisant pendant des années. Mais il y a 1 ou 2 ans ans, c'est devenu trop juste pour les 2 initramfs qu'arch génère par défaut (une image normale avec les devices détectés, et une fallback avec tous les devices). Résultat j'ai du désactiver la génération de l'image de fallback. Encore quelques années à ce rythme et je n'aurai plus non plus la place pour l'image normale.
Évidemment tu me diras que j'ai été stupide de faire un /boot aussi petit. Sauf que sans LVM, ta partition de boot, c'est un choix que tu fais à la première installation, mais que tu dois assumer pendant des années. Avec un disque de 500GB en dual boot, je n'avais d'espace à gaspiller. Le matos évolue, le software évolue. Il y a des choix qui ont un sens à un instant donné, et on ne peut pas toujours anticiper l'évolution des besoins.
-
mon SSD fait à peine 100Go
c'est largement suffisant pour un disque système
quel est le souci ? il suffit de réinstaller avec un partitionnement optimisé
on ne va quand même pas accuser Linux de faire de l'obsolescence programmée ! ;D
mon PC a une quinzaine d'années. il tourne mieux que certains Windows récents mais encrassés
PS : et oui mettre moins de 1Go en /boot me parait un choix étrange
même en 2012
-
attend je ne parlais pas de la même chose désolé
je viens de regarder mes disques
ma partition /boot fait presque 1Go (dimensionnement auto je ne touche à rien à l'install)
mais seuls 10,72Mo sont utilisés
je ne comprends pas pourquoi la tienne est aussi chargée ? ???
-
Tu confonds /boot et /boot/efi. Mon EFI fais 95MB et c'est largment suffisant.
-
je ne vois pas de quoi tu parles
je n'ai que ça sur mon disque système
-
C'est juste que tu n'as pas de partition séparée pour /boot. Ton kernel et ton inird sont directement sur /. Moi j'ai une partition dédiée à /boot (et une autre à /boot/efi).
-
ok
bah tu devras réinstaller et re-partionner à terme...
te plains pas
certains sous Windows ont du racheter un PC ! ;D 8) :-X
-
On ne parle pas du noyeau Linux, mais du paquet contenant les Micrologiciels, qui est mis à jour chaque mois.
Il n'est pas dans la partition /boot pour ceux qui en ont une.
Ubuntu 25.04
Mai 2025
(https://lafibre.info/testdebit/ubuntu/202505_ubuntu_2504_taille_noyau_linux_6-14.webp)
Juin 2025
(https://lafibre.info/testdebit/ubuntu/202506_ubuntu_2504_taille_noyau_linux_6-14.webp)
Juillet 2025
(https://lafibre.info/testdebit/ubuntu/202507_ubuntu_2504_taille_noyau_linux_6-14.webp)
Aout 2025
(https://lafibre.info/testdebit/ubuntu/202508_ubuntu_2504_taille_noyau_linux_6-14.webp)
Septembre 2025
(https://lafibre.info/testdebit/ubuntu/202509_ubuntu_2504_taille_noyau_linux_6-14.webp)
Octobre 2025
(https://lafibre.info/testdebit/ubuntu/202510_ubuntu_2504_taille_noyau_linux_6-14.webp)
Ubuntu 25.10
Novembre 2025
(https://lafibre.info/testdebit/ubuntu/202511_ubuntu_2510_taille_noyau_linux_6-17.webp)
Décembre 2025 (publié début janvier 2026)
(https://lafibre.info/testdebit/ubuntu/202512_ubuntu_2510_taille_noyau_linux_6-17.webp)
Janvier 2026
(https://lafibre.info/testdebit/ubuntu/202601_ubuntu_2510_taille_noyau_linux_6-17.webp)
-
pourquoi il n'y a pas cela sur Debian ?
c'est pour les pilotes propriétaires ?
avec le contrib-non free ça fait la même chose sur Debian ?
je sais pourquoi j'avais quitté Ubuntu pour Debian en 2015
trop de MAJ... de popup...
-
On ne parle pas du noyeau Linux, mais du paquet contenant les Micrologiciels, qui est mis à jour chaque mois.
Il n'est pas dans la partition /boot pour ceux qui en ont une.
Une partie de ces "micrologiciels" se retrouvent dans l'initrd, qui se retrouve sous /boot.
-
je crois que j'ai compris
Ubuntu et Debian n'utilisent pas tout à fait le même système de mises à jour
Debian va chercher uniquement ce dont il a besoin (y compris les pilotes propriétaires si le sources.list est bien configuré)
Ubuntu te balance toute la MAJ packagée (ce qui encombre serveurs et bande passante) puis ensuite ton système pioche ce dont il a besoin
avec en prime des MAJ bien plus fréquentes
non ?
est-ce qu'en commande (apt-get update / upgrade) ça fait pareil ?
il te prend 600Mo sur le réseau à chaque fois ?
ou c'est juste en graphique ?
-
est-ce qu'en commande (apt-get update / upgrade) ça fait pareil ?
il te prend 600Mo sur le réseau à chaque fois ?
ou c'est juste en graphique ?
Même chose en ligne de commande.
-
Pour ton besoin Leon, tu devrais tenter Debian 13.
Effectivement, avec 1,4Go après une installation fraiche juste avec le minimum dont j'ai besoin, ça me semble bien mieux. En plus Debian et Ubuntu sont "cousins", donc je ne serais pas dépaysé. Merci.
Parce que Linux, contrairement à Windows, ne garantit aucune stabilité de son ABI (https://fr.wikipedia.org/wiki/Application_binary_interface). Si un pilote est laissé en dehors du noyau, il devient incompatible très vite et se casse à la prochaine màj du noyau. En étant intégré aux mêmes dépôts de code source que le noyau, ça permet de s'assurer que les màj du noyau ne vont rien casser.
Windows a fait le contraire : ABI figée, mais par conséquent contrôle qualité fragmenté dans tous les sens, et gestion de la sécurité de l'anneau 0 (ring0) du noyau qui est de facto déléguée aux équipementiers et leur code souvent calamiteux
(Dites-moi si j'ai fait une erreur de compréhension car ça fait un bail que j'ai regardé ces détails techniques)
C'est valable pour toutes les distributions Linux? Ou alors juste Ubuntu?
Sur tous les linux, on met dans le noyau tous les drivers et firmware de tous les matériels courants des 20 dernières années?
C'est franchement pas clair pour moi, pas facile à comprendre.
Leon.
-
avec 1,4Go après une installation fraiche
Debian pèse plus que ça
là tu parles de l'installation sans interface graphique
Debian ne convient pas en graphique pour ton (très) petit disque dur
oui en gros c'est la force de Linux d'avoir tout qui marche presque partout dès le démarrage
mais ça ne prend pas de place dans le noyau
-
C'est valable pour toutes les distributions Linux? Ou alors juste Ubuntu?
Sur tous les linux, on met dans le noyau tous les drivers et firmware de tous les matériels courants des 20 dernières années?
C'est franchement pas clair pour moi, pas facile à comprendre.
Cela dépends des choix de ta distribution.
La stratégie la plus commune est de fournir un INITial RamDisk qui contient suffisamment de module critique pour trouver le volume système puis charger le reste.
La définition de "suffisamment de module critique" est différente entre Fedora (qui spécialise par défaut pour la machine) et Debian.
Mais tu peut toujours booter un linux à l'ancienne sans initrd et aucun module ...
-
C'est valable pour toutes les distributions Linux? Ou alors juste Ubuntu?
Sur tous les linux, on met dans le noyau tous les drivers et firmware de tous les matériels courants des 20 dernières années?
C'est franchement pas clair pour moi, pas facile à comprendre.
Il y a plusieurs choses :
- le kernel lui-même : il y a le code de base, et certains drivers que la distribution choisit d'intégrer directement, il peut y avoir plusieurs variantes (par exemple une version "cloud" allégée qui ne contient que ce qui est nécessaire pour les VM habituelles)
- les modules (drivers compilés en fichiers séparés), qui sont en général regroupés en plusieurs paquets (au moins un de base, et un "extra" pour le matériel plus rarement utilisé)
- les firmwares : il y en a de plus en plus, beaucoup de périphériques ne fonctionnent pas sans (ou de manière très limitée), les distributions commencent à découper un peu pour éviter de tout avoir
- l'initrd : il doit contenir un certain nombre de programmes, et des modules nécessaires au boot (drivers pour le disque ou le réseau, le GPU, ...), il peut être déjà généré (donc gros), ou l'être au moment de l'installation du paquet (et là on peut parfois choisir la liste des modules intégrés, par exemple de faire une version la plus minimaliste possible sans les fonctionalités et drivers non nécessaires à une machine donnée, quitte à ce que ça pose problème en cas de changement de HW)
Par rapport à un Windows, la philosophie est différente.
Même si c'est moins le cas aujourd'hui, Windows n'aime pas les changements de matériel : si on prend un disque et qu'on le met sur un autre PC, il n'est pas sûr qu'on puisse booter sans avoir à réinstaller (et dans tous les cas le premier boot sera long, et il faudra potentiellement rebooter ensuite avant de tout avoir de fonctionnel).
Linux au contraire a très peu de paramètres statiques liés au matériel, et a par défaut la majorité des drivers déjà installés, donc il est beaucoup plus simple de booter sur un autre PC (parfois c'est totalement transparent).
C'est notamment ça qui permet un Linux bootable depuis un DVD / une clé USB en étant très proche de la version installée, alors que les équivalents Windows sont pleins de contournements et loin d'être complets.
Rien n'interdirait de faire un Linux qui télécharge les drivers et firmwares de manière individuelle et à la demande, mais ce serait un énorme travail pour la distribution.
Il faudrait que les modules soient téléchargeables en tant que fichiers individuels, mais quand même mis à jour, avec un système pour suivre les dépendances et les modalias (d'une version à l'autre, le module à utiliser pour un contrôleur donné peut changer, ou se mettre à dépendre d'un module supplémentaire).
Et tout devrait être conservé sur les serveurs : si un utilisateur n'a pas mis à jour son kernel depuis 3 mois et branche un nouveau périphérique USB, il faudrait qu'il puisse télécharger le module (l'ABI n'étant pas stable, ça doit être celui qui correspond à la version et configuration du kernel qu'il a, ou presque).
-
si on prend un disque et qu'on le met sur un autre PC
oui c'est fascinant quand on voit ça la première fois !
tu casses ton PC mais tu récupères le disque dur pour le mettre dans un autre qui n'a rien à voir
=> ça marche !
sur Windows il faut réinstaller
-
Cela dépends des choix de ta distribution.
La stratégie la plus commune est de fournir un INITial RamDisk qui contient suffisamment de module critique pour trouver le volume système puis charger le reste.
La définition de "suffisamment de module critique" est différente entre Fedora (qui spécialise par défaut pour la machine) et Debian.
On parlait de drivers et firmware dans la discussion. Est-ce que ce sont des cas particuliers de "modules" dont tu parles?
Si oui, ça voudrait dire que Fedora n'installe que les firmware et drivers nécessaires pour chaque machine, alors que Ubuntu installe TOUT?
Par rapport à un Windows, la philosophie est différente.
Même si c'est moins le cas aujourd'hui, Windows n'aime pas les changements de matériel : si on prend un disque et qu'on le met sur un autre PC, il n'est pas sûr qu'on puisse booter sans avoir à réinstaller (et dans tous les cas le premier boot sera long, et il faudra potentiellement rebooter ensuite avant de tout avoir de fonctionnel).
Depuis les tous premiers Windows 10, la transplantation de disque dur / installation entre machines hétérogènes, ça fonctionne bien, de ce que j'ai constaté. Avant ça n'était pas le cas.
Rien n'interdirait de faire un Linux qui télécharge les drivers et firmwares de manière individuelle et à la demande, mais ce serait un énorme travail pour la distribution.
Il faudrait que les modules soient téléchargeables en tant que fichiers individuels, mais quand même mis à jour, avec un système pour suivre les dépendances et les modalias (d'une version à l'autre, le module à utiliser pour un contrôleur donné peut changer, ou se mettre à dépendre d'un module supplémentaire).
Travail énorme que Microsoft fait déjà?
Et il faut sans doute distinguer le fait de télécharger tout ou partie les drivers/firmwares et le fait d'installer tout ou partie de ces drivers/firmwares.
Parce que Linux, contrairement à Windows, ne garantit aucune stabilité de son ABI (https://fr.wikipedia.org/wiki/Application_binary_interface). Si un pilote est laissé en dehors du noyau, il devient incompatible très vite et se casse à la prochaine màj du noyau. En étant intégré aux mêmes dépôts de code source que le noyau, ça permet de s'assurer que les màj du noyau ne vont rien casser.
Et tout devrait être conservé sur les serveurs : si un utilisateur n'a pas mis à jour son kernel depuis 3 mois et branche un nouveau périphérique USB, il faudrait qu'il puisse télécharger le module (l'ABI n'étant pas stable, ça doit être celui qui correspond à la version et configuration du kernel qu'il a, ou presque).
On en revient à l'ABI Kernel linux instable entre les mises à jour. Est-ce qu'il faut comprendre que c'est le coeur du problème autour de Linux et des drivers? Qui oblige à embarquer les drivers avec le kernel? Si c'est confirmé, c'est quand même une sacrée contrainte, difficile à comprendre quand on vient d'un monde Windows.
Leon.
-
Depuis les tous premiers Windows 10, la transplantation de disque dur / installation entre machines hétérogènes, ça fonctionne bien, de ce que j'ai constaté. Avant ça n'était pas le cas.
J'ai de temps en temps des tests à faire sur Windows sur de vieux PC et j'ai donc tenté d'avoir un SSD externe sur lequel j'ai mis un dual boot Windows 10 + Ubuntu.
J'ai été très déçu, car la plupart du temps, Windows n'arrive pas se lancer et plante pendant son démarrage (ce n'est pas le cas de Linux).
-
On parlait de drivers et firmware dans la discussion. Est-ce que ce sont des cas particuliers de "modules" dont tu parles?
Habituellement ce qu'on appelle un module, c'est du code qui peut être chargé dynamiquement dans le kernel, et qui est dans un *.ko (comme les *.sys sous Windows).
Mais en fait un module dont les sources sont dans le kernel peut être compilé en module, intégré au kernel, ou désactivé (c'est dans la configuration).
Il y a des modules qui ne sont pas des drivers de périphériques, mais des parties du kernel : des bases communes à plusieurs drivers, des algos (crypto, protocoles réseau, fonctions du firewall, ...), ...
Les firmwares, c'est habituellement du code exécuté sur un microprocesseur embarqué (dans le CPU, le chipset, un périphérique, ...).
Ce sont des fichiers qui sont dynamiquement chargés par les drivers, et qui sont envoyés au périphérique (qui va les garder dans sa RAM).
Si oui, ça voudrait dire que Fedora n'installe que les firmware et drivers nécessaires pour chaque machine, alors que Ubuntu installe TOUT?
Non, il y a un découpage base/extra qui n'est pas forcément le même, mais il n'y a aucun cas où Fedora filtre à l'installation (le /lib/modules de la partition principale contient un grand nombre de modules).
En revanche, dracut (l'outil de génération d'initrd utilisé par Fedora) permet de générer un initrd spécifique à la machine, dans lequel il n'y aura que les modules nécessaires au boot.
Travail énorme que Microsoft fait déjà?
Oui, pour les drivers qui sont sur Windows Update (donc pas la totalité).
Mais le kernel Windows a une ABI stable, donc un driver n'a pas besoin d'être modifié (ou même recompilé) à chaque version du kernel.
On en revient à l'ABI Kernel linux instable entre les mises à jour. Est-ce qu'il faut comprendre que c'est le coeur du problème autour de Linux et des drivers? Qui oblige à embarquer les drivers avec le kernel? Si c'est confirmé, c'est quand même une sacrée contrainte, difficile à comprendre quand on vient d'un monde Windows.
Ca a aussi des avantages, notamment :
- le kernel peut évoluer plus facilement, en n'ayant pas besoin de versionner chaque changement et de garder d'anciennes APIs
- le kernel peut être plus optimisé, notamment pour l'embarqué : des parties peuvent être désactivées en fonction de la configuration, en simplifiant les structures de données
https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst
Pour Android, Google a developpé KMI (https://source.android.com/docs/core/architecture/kernel/stable-kmi) pour permettre de séparer d'un côté :
- les mises à jour de sécurité sur le kernel GKI (qui est fourni par Google, et doit être utilisé tel-quel), qui peuvent se mettre à jour sur les branches stable du kernel (par exemple 6.1.x => 6.1.y)
- les modules vendeur compilés par le fabricant (et dont les sources viennent souvent du vendeur du SoC)
Mais c'est avec beaucoup de contraintes : changements de configuration et de compilateur limités, listes de fonctions utilisables réduites (sur lequelles Google doit parfois adapter le code pour garder la compatibilité).
-
En revanche, dracut (l'outil de génération d'initrd utilisé par Fedora) permet de générer un initrd spécifique à la machine, dans lequel il n'y aura que les modules nécessaires au boot.
Et dracut peut également faire le tri dans les firmwares qui seront mis dans l'initrd.
Bien sur, tout cela est configurable.
Avant de faire un P2V ou un V2V (changement d'hyperviseur) d'une RHEL (et dérivés), il est recommandé de reconstruire l'initrd avec hostonly=no.
L'image Rescue censé servir dans ce cas pouvant être beaucoup trop vieille, j'ai un bug Redhat à ce sujet.
-
Cette nouvelle approche vise à réduire la taille des mises à jour de micrologiciels pour la plupart des utilisateurs. Actuellement, les fichiers de micrologiciels sont contenus dans un seul paquet dont la taille de téléchargement dépasse 500 Mo dans les versions récentes (et utilise jusqu'à 1 Go d'espace disque une fois installé).
Par conséquent, même si un correctif de sécurité est appliqué à du matériel spécialisé comme une mise à jour de 100 Ko pour les cartes réseau Netronome ou Mellanox, principalement utilisées dans les centres de données d'entreprise, tous les utilisateurs d'Ubuntu doivent télécharger l'intégralité de la mise à jour `linux-firmware` – plus de 600 Mo dans Questing.
La mise à jour de février 2026 est arrivé et c'est très limité ce mois-ci : un unique firmware est rajouté, pour la plateforme Intel PANTHER LAKE, qui a officiellement lancé au CES le 5 janvier 2026 (les premiers tests dans la presse viennent d'arriver, elle serait assez performante).
(https://lafibre.info/testdebit/ubuntu/202602_ubuntu_2510_taille_noyau_linux_6-17.webp)
-
c'est très limité ce mois-ci : un unique firmware est rajouté
mais il faut tout de même télécharger 600Mo ??! ???
-
Oui, il n'est pas encore possible de télécharger uniquement ce qui a été modifié.
-
c'est étrange comme comportement
-
dpkg n'inclus pas de fonctionnalités pour faire des delta tout simplement.
-
Pour Ubuntu 24.04, la mise à jour des micrologiciels est arrivée hier.
Cette version d'Ubuntu étant plus utilisée qu'Ubuntu 25.10 (c'était la semaine dernière la mise à jour Ubuntu 25.10), l'impact sur mon serveur miroir est bien visible :
(https://lafibre.info/testdebit/ubuntu/202602_ubuntu_2404_impact_firmwares_miroir_uybuntu_1.webp) (https://lafibre.info/testdebit/ubuntu/202602_ubuntu_2404_impact_firmwares_miroir_uybuntu_2.webp) (https://lafibre.info/testdebit/ubuntu/202602_ubuntu_2404_impact_firmwares_miroir_uybuntu_3.webp)
-
À noter que la version du noyau ne semble pas influer sur les firmwares mis à disposition.
Ubuntu 24.04 LTS comme toutes les versions LTS dispose de 2 familles de noyau, au choix de l'utilisateur : GA pour rester 15 ans avec le même noyau (avec les mises à jour de sécurité) et un noyau HWE plus récent qui permet une compatibilité avec du matériel récent) qui va évoluer tous les 6 mois les deux premières années de la LTS.
Les noyaux HWE pour Ubuntu 24.04 est actuellement le 6.17, on passera sur le noyau 7.0 en aout 2026 :
(https://lafibre.info/testdebit/ubuntu/202404_ubuntu_noyau_linux_ga_hwe_oem.svg)
Toutefois le paquet firmware semble identique sur une Ubuntu 24.04 avec le noyau 6.17 ou le noyau 6.8.
Ci-dessous, un serveur Ubuntu 24.04 LTS (sans interface graphique) avec le noyau HWE 6.17 : on est sur 560 Mo.
(https://lafibre.info/testdebit/ubuntu/202602_ubuntu_2404_taille_firmwares_noyau_linux_6-17.webp)
Ci-dessous, un PC Ubuntu 24.04 LTS (sans interface graphique) avec le noyau GA 6.8 : on est sur 560 Mo également.
(https://lafibre.info/testdebit/ubuntu/202602_ubuntu_2404_taille_firmwares_noyau_linux_6-8.webp)
Seconde mise à jour du moi pour Ubuntu 25.10 : (noyeau Linux 6.17)
(https://lafibre.info/testdebit/ubuntu/202602_ubuntu_2510_taille_firmwares_noyau_linux_6-17.webp)
-
À noter que la version du noyau ne semble pas influer sur les firmwares mis à disposition.
Certains firmwares restent compatibles, d'autres ont une version d'API (de l'interface entre le kernel et le firmware) voire peut-être une version.
Par exemple sur https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/intel/iwlwifi (les firmwares des contrôleurs Wifi Intel), on voit qu'il y a plusieurs firmwares avec le même préfixe (pour le même contrôleur), et différentes versions d'API à la fin.
Chaque kernel va supporter une ou plusieurs versions d'API, par exemple pour la famille AX210 :
- dans le kernel 6.8 : IWL_AX210_UCODE_API_MIN = 59, IWL_AX210_UCODE_API_MAX = 86, donc par exemple iwlwifi-ty-a0-gf-a0-86.ucode
- dans le kernel 6.17 : IWL_AX210_UCODE_API_MIN = 89, IWL_AX210_UCODE_API_MAX = 89, donc iwlwifi-ty-a0-gf-a0-89.ucode
Donc dans cet exemple le driver du kernel 6.8 peut fonctionner avec une très large plage de versions de linux-firmware.
Mais avec le kernel 6.17, il faut l'API 89, et donc au moins https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=4ff50358b36b2e302f55a7fed41163ce47e83a7a (17/04/2024), sachant que par la suite ce firmware a été mis à jour plusieurs fois avec la même API.