{
    "mode": "man",
    "parameter": "iucode-tool",
    "section": "8",
    "url": "https://www.chedong.com/phpMan.php/man/iucode-tool/8/json",
    "generated": "2026-06-02T21:26:41Z",
    "synopsis": "iucodetool [options] [[-ttype] filename|dirname] ...",
    "sections": {
        "NAME": {
            "content": "iucodetool - Tool to manipulate Intel® IA‐32/X86‐64 microcode bundles\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "iucodetool [options] [[-ttype] filename|dirname] ...\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "iucodetool  is  an  utility that can load Intel® processor microcode data from files in both\ntext and binary microcode bundle formats.\n\nIt can output a list of the microcodes in these files, merge them, upload them to the  kernel\n(to  upgrade the microcode in the system processor cores) or write some of them out to a file\nin binary format for later use.\n\niucodetool will load all microcodes in the specified files and directories to memory, in or‐\nder  to process them.  Duplicated and outdated microcodes will be discarded.  It can read mi‐\ncrocode data from standard input (stdin), by specifying a file name of “-” (minus sign).\n\nMicrocode data files are assumed to be in .dat text format if they have a .dat suffix, and to\nbe  in binary format otherwise.  Standard input (stdin) is assumed to be in .dat text format.\nThe -t option can be used to change the type of the files specified after it,  including  for\nstdin.\n\nIf a directory is specified, all files whose names do not begin with a dot will be loaded, in\nunspecified order.  Nested directories are skipped.\n\nEmpty files and directories are ignored, and will be skipped.\n\nYou can select which microcodes should be written out, listed or uploaded to the kernel using\nthe  -S,  -s, --date-before and --date-after options.  Should none of those options be speci‐\nfied, all microcodes will be selected.\n\nYou can upload the selected microcodes to the kernel, write them out to  a  file  (in  binary\nformat), to a Linux early initramfs archive, to per‐processor‐signature files in a directory,\nor to per‐microcode files in a directory using the -w, --write-earlyfw, -k, -K,  and  -W  op‐\ntions.\n\niucodetool will identify microcodes in its output and error messages using a “n/k” notation,\nwhere “n” is the bundle number, and “k” is the microcode number within that bundle.  The out‐\nput  of the --list-all option when processing multiple input files is the best example of how\nit works.\n\n\nFor more information about Intel processor microcodes, please read the included documentation\nand the Intel manuals listed in the SEE ALSO section.\n\n",
            "subsections": []
        },
        "OPTIONS": {
            "content": "iucodetool accepts the following options:\n\n",
            "subsections": [
                {
                    "name": "-q --quiet",
                    "content": "Inhibit usual output.\n",
                    "flag": "-q",
                    "long": "--quiet"
                },
                {
                    "name": "-v --verbose",
                    "content": "Print more information.  Use more than once for added verbosity.\n",
                    "flag": "-v",
                    "long": "--verbose"
                },
                {
                    "name": "-h -? --help",
                    "content": "List all available options and their meanings.\n",
                    "flag": "-?",
                    "long": "--help"
                },
                {
                    "name": "--usage",
                    "content": "Show summary of options.\n",
                    "long": "--usage"
                },
                {
                    "name": "-V --version",
                    "content": "Show version of program.\n\n",
                    "flag": "-V",
                    "long": "--version"
                },
                {
                    "name": "-t",
                    "content": "Sets the file type of the following files. type can be:\n\nb      binary  format.   This  is  the  same  format used by the kernel driver and the\nBIOS/EFI, which is described in detail by the Intel 64 and IA‐32  Architectures\nSoftware Developer's Manual, Volume 3A, section 9.11.\n\nd      Intel microcode .dat text format.  This is the format normally used by Intel to\ndistribute microcode data files.\n\nr      recover microcode in binary format.  Search uncompressed generic  binary  files\nfor  microcodes in Intel microcode binary format to recover.  Note: It can find\nmicrocode that will not pass strict checks, and thus cause iucodetool to  exit\nif the --no-strict-checks or --ignore-broken options are not in effect.\n",
                    "flag": "-t"
                },
                {
                    "name": "a      (default)",
                    "content": "type: .dat text format for files that have a .dat suffix, and binary type  oth‐\nerwise.  Note that for stdin, .dat text format is assumed.\n\n"
                },
                {
                    "name": "--downgrade",
                    "content": "When  multiple  versions  of the microcode for a specific processor are available from\ndifferent files, keep the one from the file loaded last, regardless of  revision  lev‐\nels.   Files  are  always loaded in the order they were specified in the command line.\nThis option has no effect when just one file has been loaded.\n\n",
                    "long": "--downgrade"
                },
                {
                    "name": "--no-downgrade",
                    "content": "When multiple versions of the microcode for a specific processor  are  available  from\ndifferent  files,  keep  the one with the highest revision level.  This is the default\nmode of operation.\n\n",
                    "long": "--no-downgrade"
                },
                {
                    "name": "--strict-checks",
                    "content": "Perform strict checks on the microcode data.  It will refuse to  load  microcodes  and\nmicrocode  data  files with unexpected size and metadata.  It will also refuse to load\nmicrocode entries that have the same metadata, but different payload.  This is the de‐\nfault mode of operation.\n\n",
                    "long": "--strict-checks"
                },
                {
                    "name": "--no-strict-checks",
                    "content": "Perform  less  strict  checks  on  the microcode data.  Use only if you happen to come\nacross a microcode data file that has microcodes with weird sizes  or  incorrect  non‐\ncritical metadata (such as invalid dates), which you want to retain.  If you just want\nto skip those, use the --ignore-broken option.\n\n",
                    "long": "--no-strict-checks"
                },
                {
                    "name": "--ignore-broken",
                    "content": "Skip broken microcode entries when loading a microcode data file, instead of  aborting\nprogram execution.  If the microcode entry has an unsupported format or had its header\nseverely corrupted, all remaining data in the file will have to be ignored.   In  that\ncase,  using  a file type of recover microcode in binary format (-tr option) is recom‐\nmended, as it can skip over badly mangled microcode data.\n\n",
                    "long": "--ignore-broken"
                },
                {
                    "name": "--no-ignore-broken",
                    "content": "Abort program execution if a broken microcode is found while loading a microcode  data\nfile.  This is the default mode of operation.\n\n\n",
                    "long": "--no-ignore-broken"
                },
                {
                    "name": "-s",
                    "content": "Select  microcodes by the specified signature, processor flags mask (pfmask), and re‐\nvision.\n\nIf the processor flags mask is specified, it will  select  only  microcodes  that  are\nsuitable for at least one of the processor flag combinations present in the mask.\n\nIf  the revision is specified, optionally prefixed by one of the “eq:”, “lt:” or “gt:”\noperators, it will select only microcodes that have that same revision (if  no  opera‐\ntor,  or  if  the  “eq:” operator is used), or microcodes that have a revision that is\nless than (“lt:” operator), or greater than (“gt:” operator), the one specified.\n\nSpecify more than once to select more microcodes.  This option can  be  combined  with\nthe  --scan-system  option to select more microcodes.  If signature is prefixed with a\n“!” (exclamation mark), it will deselect microcodes instead.  Ordering  matters,  with\nlater -s options overriding earlier ones, including --scan-system.\n\nWhen specifying signature and pfmask, hexadecimal numbers must be prefixed with “0x”,\nand octal numbers with “0”.  Decimal numbers must not have  leading  zeros,  otherwise\nthey would be interpreted as octal numbers.\n\nThe  special  notation  -s! (with no signature parameter) instructs iucodetool to re‐\nquire explicit inclusion of microcode signatures (using the non-negated form of -s, or\nusing --scan-system).\n\n",
                    "flag": "-s"
                },
                {
                    "name": "-S --scan-system",
                    "content": "Select microcodes by scanning online processors on this system for their signatures.\n\nThis option can be used only once, and it can be combined with the -s option to select\nmore microcodes.  The microcodes selected by --scan-system can also be deselected by a\nlater -s !signature option.\n\nThe  optional  mode argument (accepted only by the long version of the option) selects\nthe strategy used to scan processors:\n\n0 or auto\nCurrently the same as fast, but this might change in future versions  if  Intel\never  deploys  multi‐signature  systems that go beyond mixed‐stepping.  This is\nthe default mode of operation, for backwards compatibility with  previous  ver‐\nsions of iucodetool.\n\n1 or fast\nUses the cpuid instruction to detect the signature of the processor iucodetool\nis running on, and selects all steppings for that processor's type, family  and\nmodel.  Supports mixed‐stepping systems.\n\n2 or exact\nUses  kernel  drivers to scan the signature of every online processor directly.\nThis mode supports multi‐signature systems.  This scan mode  will  be  slow  on\nlarge  systems  with  many  processors, and likely requires special permissions\n(such as running as the root user).  Should the scan fail for any reason, as  a\nfail‐safe measure, it will issue an warning and consider all possible steppings\nfor every signature it did manage to scan successfully.\n\n\n--date-before=YYYY-MM-DD and --date-after=YYYY-MM-DD\nLimit the selected microcodes by a date range.  The date must be given in ISO  format,\nwith  four  digits  for  the  year and two digits for the month and day and “-” (minus\nsign) for the separator.  Dates are not  range‐checked,  so  you  can  use  --date-af‐\nter=2000-00-00 to select all microcodes dated since January 1st, 2000.\n\n",
                    "flag": "-S",
                    "long": "--scan-system"
                },
                {
                    "name": "--loose-date-filtering",
                    "content": "When  a date range is specified, all revisions of the microcode will be considered for\nselection (ignoring just the date range, all other filters still apply) should any  of\nthe microcode's revisions be within the date range.\n\n",
                    "long": "--loose-date-filtering"
                },
                {
                    "name": "--strict-date-filtering",
                    "content": "When  a  date  range  is  specified,  select only microcodes which are within the date\nrange.  This is the default mode of operation.\n\n",
                    "long": "--strict-date-filtering"
                },
                {
                    "name": "-l --list",
                    "content": "List selected microcode signatures to standard output (stdout).\n",
                    "flag": "-l",
                    "long": "--list"
                },
                {
                    "name": "-L --list-all",
                    "content": "List all microcode signatures while they're being processed to standard  output  (std‐\nout).\n\n",
                    "flag": "-L",
                    "long": "--list-all"
                },
                {
                    "name": "-k --kernel",
                    "content": "Upload  selected  microcodes to the kernel.  Optionally, the device path can be speci‐\nfied (default: /dev/cpu/microcode).  This update method is deprecated: it will be  re‐\nmoved eventually from the kernel and from iucodetool.\n",
                    "flag": "-k",
                    "long": "--kernel"
                },
                {
                    "name": "-K --write-firmware",
                    "content": "Write  selected  microcodes  with the file names expected by the Linux kernel firmware\nloader.   Optionally,  the  destination   directory   can   be   specified   (default:\n/lib/firmware/intel‐ucode).\n\n",
                    "flag": "-K",
                    "long": "--write-firmware"
                },
                {
                    "name": "-w --write-to",
                    "content": "Write selected microcodes to a file in binary format.\n\n\n--write-earlyfw=file\nWrite  selected microcodes to an early initramfs archive, which should be prepended to\nthe regular initramfs to allow the kernel to update  processor  microcode  very  early\nduring system boot.\n\n",
                    "flag": "-w",
                    "long": "--write-to"
                },
                {
                    "name": "-W --write-named-to",
                    "content": "Write  selected  microcodes to the specified directory, one microcode per file, in bi‐\nnary format.  The file names reflect the microcode signature, processor flags mask and\nrevision.\n\n\n--write-all-named-to=directory\nWrite  every  microcode  to the specified directory, one microcode per file, in binary\nformat.  The file names reflect the microcode signature, processor flags mask and  re‐\nvision.  This is the only way to write out every revision of the same microcode.\n\n",
                    "flag": "-W",
                    "long": "--write-named-to"
                },
                {
                    "name": "--overwrite",
                    "content": "Remove  the destination file before writing, if it exists and is not a directory.  The\ndestination file is not overwritten in‐place.  Hardlinks will be severed, and any  ex‐\nisting  access  permissions, ACLs and other extended attributes of the old destination\nfile will be lost.\n\n",
                    "long": "--overwrite"
                },
                {
                    "name": "--no-overwrite",
                    "content": "Abort if the destination file already exists.  This is the default mode of  operation.\nDo note that iucodetool does not follow non‐directory symlinks when writing files.\n\n",
                    "long": "--no-overwrite"
                },
                {
                    "name": "--mini-earlyfw",
                    "content": "Optimize the early initramfs cpio container for minimal size.  It will change the cpio\nblock size to 16 bytes, and remove header entries for the parent  directories  of  the\nmicrocode  data  file.   As a result, the microcode data file will not be available to\nthe regular initramfs, and tools might complain  about  the  non‐standard  cpio  block\nsize.\n\nThis will typically reduce the early initramfs size by 736 bytes.\n\n",
                    "long": "--mini-earlyfw"
                },
                {
                    "name": "--normal-earlyfw",
                    "content": "Optimize the early initramfs size for tool compatibility.  This is the default mode of\noperation.  The microcode data file will be available inside the regular initramfs  as\nwell.\n\n",
                    "long": "--normal-earlyfw"
                }
            ]
        },
        "NOTES": {
            "content": "iucodetool reads all data to memory before doing any processing.  It enforces a sanity limit\nof a maximum of 1GiB worth of binary microcode data per microcode data file.\n\n\nAll informational and error messages are sent to  standard  error  (stderr),  while  user‐re‐\nquested  output  (such  as  output  generated by the list options) is sent to standard output\n(stdout).\n\n\niucodetool creates files with permissions 0644 (rw-r--r--), modified by the current umask.\n\n\niucodetool's selected microcode listing and microcode output files are sorted first by  pro‐\ncessor  signature  (in  ascending order), and then by processor flags mask (in descending or‐\nder).\n\n\nWhen multiple revisions of a microcode are selected, the older ones will  be  skipped.   Only\nthe  newest  selected revision of a microcode (or the last one in load order when the --down‐\ngrade option is active) will be written to a file or uploaded to the kernel.\n\n\nIntel microcode data files, both in binary and text formats, can be concatenated to  generate\na bigger and still valid microcode data file.\n\n\niucodetool  does  not  follow  symlinks  when  writing microcode data files.  It will either\nrefuse to write the file and abort (default mode of operation), or (when the --overwrite  op‐\ntion  is active) it will remove the target symlink or file (and therefore breaking hardlinks)\nbefore writing the new file.\n\n\niucodetool does follow directory symlinks to locate the directory to write files into.\n\n",
            "subsections": [
                {
                    "name": "Linux Notes",
                    "content": "Before Linux v4.4, the microcode update driver was split in two parts:  the  early  microcode\nupdate  driver  (which  gets microcode data from the initramfs) and the late microcode update\ndriver, which could be a module and got microcode data from the firmware subsystem.  The  two\ndrivers were unified in Linux v4.4.\n\nThe  microcode  update  driver  needs  to be present in the system at all times to ensure mi‐\ncrocode updates are reapplied on resume from suspend and CPU hotplug.  Do not unload the  mi‐\ncrocode  module,  unless you really know better.  Since Linux v4.4, the late microcode driver\ncannot be a module anymore and will always be present in the system when enabled.\n\nUpdating microcode early is safer.  It can only be done at boot and it requires an initramfs,\nbut  it  is  strongly  recommended:  late  microcode  updates (which read microcode data from\n/lib/firmware) cannot safely change visible processor features.\n\nEarly microcode updates are available since Linux v3.9.  They can safely change visible  pro‐\ncessor  features (such as the microcode updates that disabled Intel TSX instructions on Intel\nHaswell cores do).  They require an uncompressed initramfs image with  the  microcode  update\ndata  in /kernel/x86/microcode/GenuineIntel.bin.  This uncompressed initramfs image must come\nbefore any compressed initramfs image(s), and it has an special name: early initramfs.\n\nThe microcode update data inside the early initramfs image  must  be  aligned  to  a  16‐byte\nboundary  due to a bug in several versions of the Linux kernel early microcode update driver.\nThis requires special steps when creating the initramfs archive with the microcode data,  and\nwill be handled automatically by the iucodetool --write-earlyfw option.\n\nSince  Linux  v4.2,  it  is also possible to build a kernel with the microcode update data as\nbuilt‐in firmware, using the CONFIGFIRMWAREINKERNEL facility.  This feature is not yet ma‐\nture as of Linux v4.2.8, v4.4.11, v4.5.5 and v4.6, and might not work in every case.\n\nThe  /dev/cpu/microcode  update interface has been deprecated and should not be used.  It has\none special requirement: each write syscall must contain whole microcode(s).  It can  be  ac‐\ncessed through iucodetool --kernel.\n\nUp  to  Linux v3.5, late microcode updates were required to be triggered per‐core, by writing\nthe number 1 to /sys/devices/system/cpu/*/microcode/reload for every cpu.  Depending on  ker‐\nnel  version,  you  must either trigger it on every core to avoid a dangerous situation where\nsome cores are using outdated microcode, or the kernel will accept the request only  for  the\nboot processor and use it to trigger an update on all system processor cores.\n\nSince  Linux v3.6, the late microcode update driver has a new interface that explicitly trig‐\ngers an update for every core at once when the  number  1  is  written  to  /sys/devices/sys‐\ntem/cpu/microcode/reload.\n\n"
                }
            ]
        },
        "EXAMPLES": {
            "content": "Updating files in /lib/firmware/intel‐ucode:\niucodetool -K/lib/firmware/intel‐ucode \\\n/lib/firmware/intel‐ucode \\\n/tmp/file-with-new-microcodes.bin\n",
            "subsections": [
                {
                    "name": "Processing several compressed files at once:",
                    "content": "zcat intel-microcode*.dat.gz | iucodetool -l -\n\nzcat intel-microcode*.bin.gz | iucodetool -l -tb -\n"
                },
                {
                    "name": "Selecting microcodes and creating an early initramfs:",
                    "content": "iucodetool --scan-system \\\n--write-earlyfw=/tmp/early.cpio \\\n/lib/firmware/intel-ucode\n\niucodetool -s 0x106a5 -s 0x106a4 -l /lib/firmware/intel-ucode\n"
                },
                {
                    "name": "Using the recovery loader to load and to update microcode in an early initramfs:",
                    "content": "iucodetool -L -tr /boot/intel-ucode.img\n\niucodetool -Ll -S --write-earlyfw=/boot/intel-ucode.img.new \\\n-tr /boot/intel-ucode.img -tb /lib/firmware/intel-ucode && \\\nmv /boot/intel-ucode.img.new /boot/intel-ucode.img\n\n"
                }
            ]
        },
        "BUGS": {
            "content": "Microcode with negative revision numbers is not special‐cased, and will not be preferred over\nregular microcode.\n\n\nThe downgrade mode should be used only for microcodes with the same processor flags mask.  It\ncannot  handle  the  corner cases where modifying a processor flags mask would be required to\nforce the kernel to load a lower revision of a microcode, and iucodetool will issue an warn‐\ning when that happens.  So far, this has not proved to be a relevant limitation as changes to\nthe processor flags mask of post‐launch, production microcode updates are very rare.\n\n\nThe loader version microcode metadata field is ignored by iucodetool.  This shouldn't  cause\nproblems as long as the same signature never needs more than a single type of loader.\n\n\nFiles  are  not  replaced  atomically: if iucodetool is interrupted while writing to a file,\nthat file will be corrupted.\n\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "The Intel 64 and IA‐‐32 Architectures Software Developer's Manual, Volume 3A: System  Program‐‐\nming Guide, Part 1 (order number 253668), section 9.11.\n",
            "subsections": []
        },
        "AUTHOR": {
            "content": "Henrique de Moraes Holschuh <hmh@hmh.eng.br>\n\n\n\nIUCODETOOL 2.3.1                            2018‐01‐28                               IUCODETOOL(8)",
            "subsections": []
        }
    },
    "summary": "iucodetool - Tool to manipulate Intel® IA‐32/X86‐64 microcode bundles",
    "flags": [
        {
            "flag": "-q",
            "long": "--quiet",
            "arg": null,
            "description": "Inhibit usual output."
        },
        {
            "flag": "-v",
            "long": "--verbose",
            "arg": null,
            "description": "Print more information. Use more than once for added verbosity."
        },
        {
            "flag": "-?",
            "long": "--help",
            "arg": null,
            "description": "List all available options and their meanings."
        },
        {
            "flag": "",
            "long": "--usage",
            "arg": null,
            "description": "Show summary of options."
        },
        {
            "flag": "-V",
            "long": "--version",
            "arg": null,
            "description": "Show version of program."
        },
        {
            "flag": "-t",
            "long": null,
            "arg": null,
            "description": "Sets the file type of the following files. type can be: b binary format. This is the same format used by the kernel driver and the BIOS/EFI, which is described in detail by the Intel 64 and IA‐32 Architectures Software Developer's Manual, Volume 3A, section 9.11. d Intel microcode .dat text format. This is the format normally used by Intel to distribute microcode data files. r recover microcode in binary format. Search uncompressed generic binary files for microcodes in Intel microcode binary format to recover. Note: It can find microcode that will not pass strict checks, and thus cause iucodetool to exit if the --no-strict-checks or --ignore-broken options are not in effect."
        },
        {
            "flag": "",
            "long": "--downgrade",
            "arg": null,
            "description": "When multiple versions of the microcode for a specific processor are available from different files, keep the one from the file loaded last, regardless of revision lev‐ els. Files are always loaded in the order they were specified in the command line. This option has no effect when just one file has been loaded."
        },
        {
            "flag": "",
            "long": "--no-downgrade",
            "arg": null,
            "description": "When multiple versions of the microcode for a specific processor are available from different files, keep the one with the highest revision level. This is the default mode of operation."
        },
        {
            "flag": "",
            "long": "--strict-checks",
            "arg": null,
            "description": "Perform strict checks on the microcode data. It will refuse to load microcodes and microcode data files with unexpected size and metadata. It will also refuse to load microcode entries that have the same metadata, but different payload. This is the de‐ fault mode of operation."
        },
        {
            "flag": "",
            "long": "--no-strict-checks",
            "arg": null,
            "description": "Perform less strict checks on the microcode data. Use only if you happen to come across a microcode data file that has microcodes with weird sizes or incorrect non‐ critical metadata (such as invalid dates), which you want to retain. If you just want to skip those, use the --ignore-broken option."
        },
        {
            "flag": "",
            "long": "--ignore-broken",
            "arg": null,
            "description": "Skip broken microcode entries when loading a microcode data file, instead of aborting program execution. If the microcode entry has an unsupported format or had its header severely corrupted, all remaining data in the file will have to be ignored. In that case, using a file type of recover microcode in binary format (-tr option) is recom‐ mended, as it can skip over badly mangled microcode data."
        },
        {
            "flag": "",
            "long": "--no-ignore-broken",
            "arg": null,
            "description": "Abort program execution if a broken microcode is found while loading a microcode data file. This is the default mode of operation."
        },
        {
            "flag": "-s",
            "long": null,
            "arg": null,
            "description": "Select microcodes by the specified signature, processor flags mask (pfmask), and re‐ vision. If the processor flags mask is specified, it will select only microcodes that are suitable for at least one of the processor flag combinations present in the mask. If the revision is specified, optionally prefixed by one of the “eq:”, “lt:” or “gt:” operators, it will select only microcodes that have that same revision (if no opera‐ tor, or if the “eq:” operator is used), or microcodes that have a revision that is less than (“lt:” operator), or greater than (“gt:” operator), the one specified. Specify more than once to select more microcodes. This option can be combined with the --scan-system option to select more microcodes. If signature is prefixed with a “!” (exclamation mark), it will deselect microcodes instead. Ordering matters, with later -s options overriding earlier ones, including --scan-system. When specifying signature and pfmask, hexadecimal numbers must be prefixed with “0x”, and octal numbers with “0”. Decimal numbers must not have leading zeros, otherwise they would be interpreted as octal numbers. The special notation -s! (with no signature parameter) instructs iucodetool to re‐ quire explicit inclusion of microcode signatures (using the non-negated form of -s, or using --scan-system)."
        },
        {
            "flag": "-S",
            "long": "--scan-system",
            "arg": null,
            "description": "Select microcodes by scanning online processors on this system for their signatures. This option can be used only once, and it can be combined with the -s option to select more microcodes. The microcodes selected by --scan-system can also be deselected by a later -s !signature option. The optional mode argument (accepted only by the long version of the option) selects the strategy used to scan processors: 0 or auto Currently the same as fast, but this might change in future versions if Intel ever deploys multi‐signature systems that go beyond mixed‐stepping. This is the default mode of operation, for backwards compatibility with previous ver‐ sions of iucodetool. 1 or fast Uses the cpuid instruction to detect the signature of the processor iucodetool is running on, and selects all steppings for that processor's type, family and model. Supports mixed‐stepping systems. 2 or exact Uses kernel drivers to scan the signature of every online processor directly. This mode supports multi‐signature systems. This scan mode will be slow on large systems with many processors, and likely requires special permissions (such as running as the root user). Should the scan fail for any reason, as a fail‐safe measure, it will issue an warning and consider all possible steppings for every signature it did manage to scan successfully. --date-before=YYYY-MM-DD and --date-after=YYYY-MM-DD Limit the selected microcodes by a date range. The date must be given in ISO format, with four digits for the year and two digits for the month and day and “-” (minus sign) for the separator. Dates are not range‐checked, so you can use --date-af‐ ter=2000-00-00 to select all microcodes dated since January 1st, 2000."
        },
        {
            "flag": "",
            "long": "--loose-date-filtering",
            "arg": null,
            "description": "When a date range is specified, all revisions of the microcode will be considered for selection (ignoring just the date range, all other filters still apply) should any of the microcode's revisions be within the date range."
        },
        {
            "flag": "",
            "long": "--strict-date-filtering",
            "arg": null,
            "description": "When a date range is specified, select only microcodes which are within the date range. This is the default mode of operation."
        },
        {
            "flag": "-l",
            "long": "--list",
            "arg": null,
            "description": "List selected microcode signatures to standard output (stdout)."
        },
        {
            "flag": "-L",
            "long": "--list-all",
            "arg": null,
            "description": "List all microcode signatures while they're being processed to standard output (std‐ out)."
        },
        {
            "flag": "-k",
            "long": "--kernel",
            "arg": null,
            "description": "Upload selected microcodes to the kernel. Optionally, the device path can be speci‐ fied (default: /dev/cpu/microcode). This update method is deprecated: it will be re‐ moved eventually from the kernel and from iucodetool."
        },
        {
            "flag": "-K",
            "long": "--write-firmware",
            "arg": null,
            "description": "Write selected microcodes with the file names expected by the Linux kernel firmware loader. Optionally, the destination directory can be specified (default: /lib/firmware/intel‐ucode)."
        },
        {
            "flag": "-w",
            "long": "--write-to",
            "arg": null,
            "description": "Write selected microcodes to a file in binary format. --write-earlyfw=file Write selected microcodes to an early initramfs archive, which should be prepended to the regular initramfs to allow the kernel to update processor microcode very early during system boot."
        },
        {
            "flag": "-W",
            "long": "--write-named-to",
            "arg": null,
            "description": "Write selected microcodes to the specified directory, one microcode per file, in bi‐ nary format. The file names reflect the microcode signature, processor flags mask and revision. --write-all-named-to=directory Write every microcode to the specified directory, one microcode per file, in binary format. The file names reflect the microcode signature, processor flags mask and re‐ vision. This is the only way to write out every revision of the same microcode."
        },
        {
            "flag": "",
            "long": "--overwrite",
            "arg": null,
            "description": "Remove the destination file before writing, if it exists and is not a directory. The destination file is not overwritten in‐place. Hardlinks will be severed, and any ex‐ isting access permissions, ACLs and other extended attributes of the old destination file will be lost."
        },
        {
            "flag": "",
            "long": "--no-overwrite",
            "arg": null,
            "description": "Abort if the destination file already exists. This is the default mode of operation. Do note that iucodetool does not follow non‐directory symlinks when writing files."
        },
        {
            "flag": "",
            "long": "--mini-earlyfw",
            "arg": null,
            "description": "Optimize the early initramfs cpio container for minimal size. It will change the cpio block size to 16 bytes, and remove header entries for the parent directories of the microcode data file. As a result, the microcode data file will not be available to the regular initramfs, and tools might complain about the non‐standard cpio block size. This will typically reduce the early initramfs size by 736 bytes."
        },
        {
            "flag": "",
            "long": "--normal-earlyfw",
            "arg": null,
            "description": "Optimize the early initramfs size for tool compatibility. This is the default mode of operation. The microcode data file will be available inside the regular initramfs as well."
        }
    ],
    "examples": [
        "Updating files in /lib/firmware/intel‐ucode:",
        "iucodetool -K/lib/firmware/intel‐ucode \\",
        "/lib/firmware/intel‐ucode \\",
        "/tmp/file-with-new-microcodes.bin",
        "zcat intel-microcode*.dat.gz | iucodetool -l -",
        "zcat intel-microcode*.bin.gz | iucodetool -l -tb -",
        "iucodetool --scan-system \\",
        "--write-earlyfw=/tmp/early.cpio \\",
        "/lib/firmware/intel-ucode",
        "iucodetool -s 0x106a5 -s 0x106a4 -l /lib/firmware/intel-ucode",
        "iucodetool -L -tr /boot/intel-ucode.img",
        "iucodetool -Ll -S --write-earlyfw=/boot/intel-ucode.img.new \\",
        "-tr /boot/intel-ucode.img -tb /lib/firmware/intel-ucode && \\",
        "mv /boot/intel-ucode.img.new /boot/intel-ucode.img"
    ],
    "see_also": []
}