On my CentOS, a yum update brings up the following:

(6/38): iwl1000-firmware-                                                                                                                                            
(7/38): iwl105-firmware-                                                                             
(8/38): iwl135-firmware-                                                                             
(9/38): iwl2000-firmware-                                                                            
(10/38): iwl2030-firmware-                                                                           
(11/38): iwl3160-firmware-                                                                                                                                             


These being so-called "firmware packages". For example, let's find a few of them that are installed:

rpm --query --all | grep firmware

and then query its info:

rpm --query --info iwl105-firmware-

and we get:

Summary     : Firmware for Intel(R) Centrino Wireless-N 105 Series Adapters
Description :
This package contains the firmware required by the iwlagn driver
for Linux to support the iwl105 hardware.  Usage of the firmware
is subject to the terms and conditions contained inside the provided
LICENSE file. Please read it carefully.

Ok, well.

I don't even have that kind of hardware, as this is a VM.

So, question:

What do the firmware packages actually do?

Are they "one-shot" installs that run an opaque executable (immediately? on next boot?) which checks whether the hardware exists, pumps binary code into the hardware's flash if the hardware is there (maybe while asking the user; on Windows at least, hardware flashing is always fraught with DOS windows that pop up, EULAs that have to been clicked through, and progress bars that have to be endured), and then marks the package as "installed".

Do they modify the initramfs so that a binary blob is loaded by a kernel module or something happens at the next boot?


4 Answers 4


As Anthony Geoghegan mentions, What is "firmware" in Linux terminology? and Why do some drivers still require firmware? provide useful background.

Firmware packages are packages which contain firmware files, i.e. files which contain code which is intended to run on devices in or connected to your system — common examples include wifi chipsets, as in your case. They are not one-shot installers, and they do not care whether the hardware is available. The files they make available are used by the corresponding kernel drivers, if the relevant hardware is present: the drivers load the firmware into memory attached to the target hardware, which then runs the firmware to operate.

These firmware packages aren’t related to the firmware installers you’re thinking about, which load firmware updates into flash memory (which only needs to be done when an update is required). That process is indeed lengthy, often complex, and seemingly fraught with danger (at least, if you base your impressions on the manufacturer’s warnings). Firmware packages included in Linux distributions contain firmware which is needed every time the system boots, because it is loaded into volatile memory.


Loadable firmware is typically not "one-shot" installs that are written to flash on the device. The firmware is loaded into volatile storage on the device and needs to be done each time the host computer is turned on. The device does not function before the firmware is loaded. The firmware can be written to RAM on the device, in which case it contains code and data for the processor on the device, but it can also be a bit stream defining the logic of a field-programmable logic array (FPGA), or some combination of both.

On the other hand, firmware in flash memory is typically pre-programmed on the devices, and only needs to be rewritten if there is an update to the firmware from the manufacturer. This is typically done via other mechanisms, like a separate executable that is run by the user.

There are a few reasons why manufacturers want to use RAM instead of flash memory. First of all, it makes it possible to design a single version of the hardware, but at the same time deliver several versions of the product (for different market areas, for example). If the product is expected to be field-upgraded frequently, it may be easier to handle the firmware upgrades this way than go through the trouble of creating a program for upgrading the flash memory on the device. This program should have a nice user interface and be designed to be as user friendly as possible, since it is typically intended run by the end user of the product. Some devices with flash storage often run code from RAM anyway, and they just copy the contents of the flash to RAM when the device is started, in which case the flash chip just sits idle most of the time and is an extra expense.

  • If the firmware is not loaded into RAM from flash, how is the firmware loaded into RAM after the device turns on?
    – Codebling
    Commented Oct 14, 2019 at 2:58
  • If the device cannot autonomously load the firmware, the host can store it into the RAM of the device, using the bus with which the device is connected to the host. Typical buses are PCI and USB. It is the device driver's responsibility to do that. The device can't be totally "dead" after power on, it must contain logic to facilitate the loading of the firmware. Commented Oct 14, 2019 at 5:17
  • I kind of forgot that we were talking about peripherals here, so it will always be attached to a bus. Makes sense!
    – Codebling
    Commented Oct 14, 2019 at 17:11

Adding to the already excellent answers.

Firmware files, aka proprietary binary blobs, are loaded into your firmware at least at the time of cold (re)boots of the device.

The device was so devised to get firmware in RAM instead of having a ROM+RAM to cut down in costs of production. As example, you have some Broadcom wifi chipsets and internal switch chipsets that work that way.

Addressing the other point of your question of using firmware files in a VM.

As you are dealing with a VM, you do not need firmware files. They won't be loaded anywhere; much less ethernet or wifi "firmware" files.

Likewise, considering firmware is not needed in a VM environment, it is a big idiosyncrasy having in Debian the dependencies on a generic firmware file package in the Linux kernel.

  • “it is a big idiosyncrasy having in Debian the dependencies on a generic firmware file package in the Linux kernel” — at least the firmware which is recommended by the kernel package is really DFSG-free ;-). (But you’re right, both recommendations — firmware-linux-free and irqbalance — are useless in most deployments nowadays.) Commented Jul 14, 2018 at 16:00
  • I always run a playbook to uninstall that cruft after a round of kernel upgrades Commented Jul 14, 2018 at 16:37
  • 1
    You could also configure apt so it doesn’t install recommendations by default... Commented Jul 14, 2018 at 16:41

refer to other people's answers, and online docs
try to compare it with related things which linux users may often see.

//May not be completely accurate, improvements are welcome


Description: Firmware for Linux kernel drivers This package provides firmware used by Linux kernel drivers.

// kernel (maybe) push binary to other SoC's RAM(wifi,graphics card..) every system boot

// run in other (maybe a peripheral) cpu/mcu (RAM)



Depends: linux-image-5.4.0-110-generic, linux-modules-extra-5.4.0-110-generic, linux-firmware, intel-microcode, amd64-microcode

Description: Generic Linux kernel image This package will always depend on the latest generic kernel image available.

// kernel & drivers, NOTICE: kernel/driver may match with specified linux-firmware version

// run in cpu

device firmware

$ fwupdmgr get-devices
│ │   Device ID:          d432baa2162a...
│ │   Summary:            Fingerprint reader
│ │   Current version:    10.01.3273255
│ │   Vendor:             Synaptics (USB:0x06CB)
│ │   Install Duration:   2 seconds
│ │   Device Flags:       • Updatable
│ │                       • Supported on remote server
│ │                       • Cryptographic hash verification is available

// flash to peripheral's flash (ROM), for example BIOS update.

flash in user space,

  • fwupdmgr or
  • snap-store (named "ubuntu software") updates tab



  • CPU:
    // run in CPU: kernel, driver
  • SoC
    • load to RAM: linux-firmware binary
    • flash to ROM: device firmware

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .