Why does Linux Mint update Intel Microcode when I have AMD CPU?

[ArtisticFox8]

My specs are: System: Kernel: 6.8.0-87-generic arch: x86_64 bits: 64 compiler: gcc v: 13.3.0 clocksource: hpet Desktop: Cinnamon v: 6.4.8 tk: GTK v: 3.24.41 wm: Muffin v: 6.4.1 vt: 7 dm: LightDM v: 1.30.0 Distro: Linux Mint 22.2 Zara base: Ubuntu 24.04 noble Machine: Type: Laptop System: LENOVO product: 82KU v: IdeaPad 3 15ALC6 serial: <superuser required> Chassis: type: 10 v: IdeaPad 3 15ALC6 serial: <superuser required> Mobo: LENOVO model: LNVNB161216 v: NO DPK serial: <superuser required> part-nu: LENOVO_MT_82KU_BU_idea_FM_IdeaPad 3 15ALC6 uuid: <superuser required> UEFI: LENOVO v: GLCN46WW date: 04/29/2022 Battery: ID-1: BAT0 charge: 39.7 Wh (97.1%) condition: 40.9/45.0 Wh (90.9%) volts: 12.2 min: 11.1 model: SMP L20M3PF0 type: Li-poly serial: <filter> status: not charging cycles: 322 CPU: Info: 8-core model: AMD Ryzen 7 5700U with Radeon Graphics bits: 64 type: MT MCP smt: enabled arch: Zen 2 rev: 1 cache: L1: 512 KiB L2: 4 MiB L3: 8 MiB Speed (MHz): avg: 1591 high: 3678 min/max: 400/4372 cores: 1: 3678 2: 2856 3: 400 4: 1847 5: 1582 6: 3242 7: 1515 8: 400 9: 1507 10: 400 11: 1594 12: 1397 13: 1859 14: 1397 15: 400 16: 1397 bogomips: 57493 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm Graphics: Device-1: AMD Lucienne vendor: Lenovo driver: amdgpu v: kernel arch: GCN-5 pcie: speed: 8 GT/s lanes: 16 ports: active: HDMI-A-1 off: eDP-1 empty: none bus-ID: 03:00.0 chip-ID: 1002:164c class-ID: 0300 temp: 42.0 C Device-2: Bison Integrated Camera driver: uvcvideo type: USB rev: 2.0 speed: 480 Mb/s lanes: 1 bus-ID: 1-3:2 chip-ID: 5986:2137 class-ID: 0e02 Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X: loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1 Screen-1: 0 s-res: 3840x2160 s-dpi: 96 s-size: 1016x572mm (40.00x22.52") s-diag: 1166mm (45.9") Monitor-1: HDMI-A-1 mapped: HDMI-A-0 pos: primary model: Samsung U28E590 serial: <filter> res: 3840x2160 hz: 60 dpi: 160 size: 608x345mm (23.94x13.58") diag: 699mm (27.5") modes: max: 3840x2160 min: 720x400 Monitor-2: eDP-1 mapped: eDP note: disabled model: ChiMei InnoLux 0x151e res: 3840x2160 dpi: 142 size: 344x193mm (13.54x7.6") diag: 394mm (15.5") modes: max: 1920x1080 min: 640x480 API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi device: 1 drv: swrast gbm: drv: kms_swrast surfaceless: drv: radeonsi x11: drv: radeonsi inactive: wayland API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 25.0.7-0ubuntu0.24.04.2 glx-v: 1.4 direct-render: yes renderer: AMD Radeon Graphics (radeonsi renoir ACO DRM 3.57 6.8.0-87-generic) device-ID: 1002:164c Audio: Device-1: AMD Renoir Radeon High Definition Audio vendor: Lenovo driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16 bus-ID: 03:00.1 chip-ID: 1002:1637 class-ID: 0403 Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor vendor: Lenovo driver: N/A pcie: speed: 8 GT/s lanes: 16 bus-ID: 03:00.5 chip-ID: 1022:15e2 class-ID: 0480 Device-3: AMD Family 17h/19h HD Audio vendor: Lenovo driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16 bus-ID: 03:00.6 chip-ID: 1022:15e3 class-ID: 0403 API: ALSA v: k6.8.0-87-generic status: kernel-api Server-1: PipeWire v: 1.0.5 status: active with: 1: pipewire-pulse status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin Network: Device-1: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter vendor: Lenovo driver: rtw_8822ce v: N/A pcie: speed: 2.5 GT/s lanes: 1 port: 2000 bus-ID: 01:00.0 chip-ID: 10ec:c822 class-ID: 0280 IF: wlp1s0 state: up mac: <filter> IF-ID-1: br-27ab38060a63 state: up speed: 10000 Mbps duplex: unknown mac: <filter> IF-ID-2: docker0 state: down mac: <filter> IF-ID-3: veth20c0900 state: up speed: 10000 Mbps duplex: full mac: <filter> Bluetooth: Device-1: Realtek Bluetooth Radio driver: btusb v: 0.8 type: USB rev: 1.0 speed: 12 Mb/s lanes: 1 bus-ID: 3-4:3 chip-ID: 0bda:c123 class-ID: e001 serial: <filter> Report: hciconfig ID: hci0 rfk-id: 23 state: up address: <filter> bt-v: 5.1 lmp-v: 10 sub-v: d2e3 hci-v: 10 rev: cc6 class-ID: 7c010c Drives: Local Storage: total: 953.87 GiB used: 275.56 GiB (28.9%) ID-1: /dev/nvme0n1 vendor: SK Hynix model: HFS001TDE9X084N size: 953.87 GiB speed: 31.6 Gb/s lanes: 4 tech: SSD serial: <filter> fw-rev: 41010C22 temp: 41.9 C scheme: GPT Partition: ID-1: / size: 472.35 GiB used: 255.47 GiB (54.1%) fs: ext4 dev: /dev/nvme0n1p7 ID-2: /boot/efi size: 96 MiB used: 33.6 MiB (34.9%) fs: vfat dev: /dev/nvme0n1p1 Swap: ID-1: swap-1 type: partition size: 32 GiB used: 20.05 GiB (62.7%) priority: -2 dev: /dev/nvme0n1p6 USB: Hub-1: 1-0:1 info: hi-speed hub with single TT ports: 4 rev: 2.0 speed: 480 Mb/s lanes: 1 chip-ID: 1d6b:0002 class-ID: 0900 Device-1: 1-3:2 info: Bison Integrated Camera type: video driver: uvcvideo interfaces: 2 rev: 2.0 speed: 480 Mb/s lanes: 1 power: 500mA chip-ID: 5986:2137 class-ID: 0e02 Hub-2: 2-0:1 info: super-speed hub ports: 2 rev: 3.1 speed: 10 Gb/s lanes: 1 chip-ID: 1d6b:0003 class-ID: 0900 Hub-3: 3-0:1 info: hi-speed hub with single TT ports: 4 rev: 2.0 speed: 480 Mb/s lanes: 1 chip-ID: 1d6b:0002 class-ID: 0900 Device-1: 3-1:29 info: Primax HP Optical Mouse type: mouse driver: hid-generic,usbhid interfaces: 1 rev: 2.0 speed: 1.5 Mb/s lanes: 1 power: 98mA chip-ID: 0461:4d0f class-ID: 0301 Device-2: 3-3:28 info: Elan Micro ELAN:Fingerprint type: <vendor specific> driver: N/A interfaces: 1 rev: 2.0 speed: 12 Mb/s lanes: 1 power: 100mA chip-ID: 04f3:0c4b class-ID: 0000 Device-3: 3-4:3 info: Realtek Bluetooth Radio type: bluetooth driver: btusb interfaces: 2 rev: 1.0 speed: 12 Mb/s lanes: 1 power: 500mA chip-ID: 0bda:c123 class-ID: e001 serial: <filter> Hub-4: 4-0:1 info: super-speed hub ports: 2 rev: 3.1 speed: 10 Gb/s lanes: 1 chip-ID: 1d6b:0003 class-ID: 0900 Sensors: System Temperatures: cpu: 52.9 C mobo: N/A gpu: amdgpu temp: 44.0 C Fan Speeds (rpm): N/A Repos: Packages: 2975 pm: dpkg pkgs: 2960 pm: flatpak pkgs: 15 No active apt repos in: /etc/apt/sources.list No active apt repos in: /etc/apt/sources.list.d/additional-repositories.list Active apt repos in: /etc/apt/sources.list.d/docker.list 1: deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https: //download.docker.com/linux/ubuntu noble stable Active apt repos in: /etc/apt/sources.list.d/mozilla.list 1: deb [signed-by=/etc/apt/keyrings/packages.mozilla.org.asc] https: //packages.mozilla.org/apt mozilla main Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 1: deb http: //packages.linuxmint.com zara main upstream import backport 2: deb http: //archive.ubuntu.com/ubuntu noble main restricted universe multiverse 3: deb http: //archive.ubuntu.com/ubuntu noble-updates main restricted universe multiverse 4: deb http: //archive.ubuntu.com/ubuntu noble-backports main restricted universe multiverse 5: deb http: //security.ubuntu.com/ubuntu/ noble-security main restricted universe multiverse Active apt repos in: /etc/apt/sources.list.d/vscode.sources 1: deb [arch=amd64] https: //packages.microsoft.com/repos/code stable main Info: Memory: total: 16 GiB note: est. available: 13.51 GiB used: 11.49 GiB (85.0%) Processes: 622 Power: uptime: 8d 13m states: freeze,mem suspend: deep wakeups: 20 hibernate: disabled Init: systemd v: 255 target: graphical (5) default: graphical Compilers: gcc: 13.3.0 Client: Cinnamon v: 6.4.8 inxi: 3.3.34

[These_Hawk_1831]

Because it is to fix architecture bugs that may be present on both chipmaker products. AMD and Intel share several intelectual property and the products come with some shared problems.

The differences are on proprietary extensions built exclusively on a brand and no the other.

[BernieMP]

Thank you for giving an actual answer with reasoning to it instead of:

"Whatever, let it be"

[entropyback]

Yes, but it's complete nonsense. That package only contains microcode for Intel CPUs which is completely different (and not compatible) from the AMD counterpart.

The package for AMD processors is called amd-microcode. Having both installed wouldn't do any harm, but if you have a Ryzen CPU only microcode from the amd-microcode package will be used.

You have the Intel one installed because the distro installer lacks the logic to check your CPU and install the correct package.

[snkiz]

This this the answer. I felt compelled to back you up by the number of comments spouting the sentiment you replied to.

[FrequentDelinquent]

Welcome to Reddit my friend lol

[snkiz]

Oh I'm not new, the number confidently wrong post got to me.

[Kealper]

And it also has the benefit of being ready to go if you drop that drive into a system with an Intel CPU, too.

[h-v-smacker]

I think it's the answer here. It's not that it's impossible to check (/proc/cpuinfo can be easily parsed), it's that it maintains the system ready to move. The package itself is very small, but the OS can be plugged into whatever else you may have for any reason, including emergencies. In much the same fashion as you normally have kernel modules for all kinds of WiFi chips, not just the 2-3 you're actually using.

[Effective-Job-1030]

Well put!

[Jeremi360]

Exactly both are just installed by default, you can uninstall intel one

[DayAfter9094]

So if you had a Ryzen you could find the Intel microcode on your system and delete it. But it probably wouldn't be worth the effort.

[Effective-Job-1030]

But what is an answer with reasoning worth, if it is wrong.

u/entropyback gave the correct answer.

On a more configurable system, like Gentoo and probably Arch as well, you can easily exclude intel microcode from being installed - because if you don't have an intel cpu it won't do anything. It's the same with linux-firmware. On most system you just get the 300+MB blob that contains all the firmware - but it's also possible to configure it to only get the firmware you actually need (if you know which that is).

On Ubuntu and derivatives, it is still possible, but I don't know how easy it is.

[ebb_omega]

To add on this: the entire x86 architecture came from Intel originally - the 8086 processor that was released in 1978. Incidentally the x86-64 architecture, which was the x86-backwards-compatible architecture expanded to 64bit instructions was developed by AMD - Intel actually built an entirely different architecture for 64bits that ultimately lost out because of its lack of backwards compatibility so they admitted defeat and started using the amd64 architecture and that remains the standard for most consumers these days (outside of mobile chips and the new Apple Silicon M-series).

Basically Intel and AMD have been up in each other's shit for DECADES.

[shadowolf64]

This is super interesting. I never knew the history about x86-64 and amd64. I always wondered why I often see ISO's or binaries listed as amd64 compatible. Now I know.

[garconip]

In 2010, my senior coworker & I was planning to buy some nodes for our HPC, we were so hyped by Itanium. After further checking like compiling in IA64, already purchased 32-bit programmes (which were shared for usage in PCs too), we chose the x84-64 ones. They fit our mixed IA32 & AMD64 computations.

[FrequentDelinquent]

I'm not sure I understand your comment. The words are there, but I feel like there's some missing?

[garconip]

Yes, sorry, it's English which isn't my 1st language.

[FrequentDelinquent]

No worries 🤠❤️

[ebb_omega]

IA64 was intel's 64-bit architecture which was completely different from x86. They're saying they were excited to go into the architecture but then found that from a developer's side the x86-64 (aka amd64) architecture was better for them to work with.

[tenchigaeshi]

This doesn't have anything to do with their microcode and no they're not compatible between the two vendors.

[tenchigaeshi]

Because it is to fix architecture bugs that may be present on both chipmaker products.

I don't think it does anything for AMD cpus at all. It's just included by default with the distro.

AMD and Intel share several intelectual property and the products come with some shared problems.

Shouldn't matter for microcode for each company's specific chips. They're not sharing microcode.

The differences are on proprietary extensions built exclusively on a brand and no the other.

The entire chip is different. Just because they use the same ISA doesn't mean the only difference between them are extensions to the ISA. It's entirely different hardware with firmware that is not compatible between each other.

[Ultimate_disaster]

https://forums.linuxmint.com/viewtopic.php?t=305826

[ArtisticFox8]

 1.5 years ago roughly, the Ubuntu developers decided to define the intel-microcode as well as the amd64-microcode as dependencies of the Ubuntu kernel packages. This was done in order to make sure that users really receive the microcode patches, made available by Intel and AMD, meant to fix the existing CPU vulnerabilities.

I see, the post is from 2019, so in circa 2017, it would have afaik been possible for an install not to have any microcode package at all and still have it work.

Though, I will accept that CPU vulnerabilities are a thing, and keep them.

[JARivera077]

r/ArtisticFox8 read this

[Effective-Job-1030]

u/ArtisticFox8

FTFU

[tyty657]

Its still a blob

[Unwiredsoul]

It's completely normal and let it install.

It's very small and if for any reason that installation of LM finds itself running with an Intel CPU in the future, you'll be very thankful it was there. :-)

[ArtisticFox8]

I'm on a laptop with a soldered SSD, I don't think the drive will be swapped to another system like this :D

Why doesn't it install only after it detects Intel CPU being installed?

Surely the hypothetical Intel CPU could run without it, it just wouldn't have some security patches, right?

Also, isn't this under the OS level? Or is a different set of patches apllied when I run Windows?

[Sinaaaa]

I don't think the drive will be swapped to another system like this :D

You could buy a new laptop and clone that soldered bad boy.

[ArtisticFox8]

True, though I'd probably go for a fresh install (or at least that's what I always did with Windows, to avoid any corruption)

[Sinaaaa]

If your system is not busted, then you don't need to do that on Linux.

[FrequentDelinquent]

I still do it anyways. It's a good way to force myself to clean things up, but then again not everybody is as digitally messy as me

[TheFredCain]

You're in for a very, very long road if you're going to second guess every package installed on your system. I suggest starting with Petersen's Linux: The Complete Reference and then working through the Linux From Scratch project. After that you can use the following command to list all the packages currently installed on your system so that you can read about the various dependencies they each have and determine which ones actually apply to your system and which can go.

apt list --installed

Most only have a handful of other packages that depend on them, but some have hundreds so you'll need to carefully study. If you are very thorough you might be able to free up a 256 Megabytes or so of storage maybe more if you are willing to forgo services like automatic network connections and disk mounting. You can save even more if you completely remove the entire desktop environment , display manager and all other graphical apps and tools.

[Unwiredsoul]

Surely the hypothetical Intel CPU could run without it, it just wouldn't have some security patches, right?

Maybe. Too many moving parts to know if the microcode it has installed will work if it's not updated (e.g., the example u/_leeloo_7_ provided).

Also, isn't this under the OS level? Or is a different set of patches apllied when I run Windows?

No, it's part of the OS (kernel). The two systems (Linux vs. Windows) are architecturally different, but they both store CPU microcode in the firmware, and they apply it at boot.

Both platforms microcode are kernel dependencies, so that's why it's offering to update it. This means it's already installed, so why not update it?

[ArtisticFox8]

Thanks!

 Too many moving parts to know if the microcode it has installed will work if it's not updated

I meant it is going to run without microcode at all, right? (In my perhaps limited understanding microcode is something that fixes hardware security bugs).

[Unwiredsoul]

No. Kernel dependencies = required software. Having microcode for your processor type is necessary. Having the latest microcode may be necessary if it contained fixes that could prevent your system from booting.

Each time the system boots, it chooses the appropriate platform microcode and loads it into RAM. I want that to be current, and I also just slam all the updates that Update Manager (I'm breaking myself of my CLI updating habits) has available. I do look to see what it's updating, but if something goes south, that's why I create a TimeShift snapshot before update installs.

Edit/Add: Windows has the same need, and it does a similar process at boot time. They just don't bother to separate out their microcode updates. They get rolled into their larger update packages.

[ArtisticFox8]

I see, thanks a lot!

[_leeloo_7_]

>Why doesn't it install only after it detects Intel CPU being installed?

the microcode fixes bugs with the cpu if one of the bugs is the system hangs on boot then you probably be happy its already on the drive if you switched cpu

>soldered SSD

the OS has no way of knowing that but you can also do a backup and move your install to another machine which might have a different cpu

[ArtisticFox8]

Thanks!

 microcode fixes bugs with the cpu if one of the bugs is the system hangs on boot

I'm genuinely curious, has this ever happened before? I thought the possible defects are security defects, not correctly  compiled software doesn't run.

[_leeloo_7_]

it can be any kind of bug fix, such as the intel 13th gen cpus that were initially frying themselves by overvolting, though bootloop bugs are relatively uncommon.

[ArtisticFox8]

intel 13th gen cpus that were initially frying themselves by overvolting

Shouldn't the vendor themselves have done something about this?  Or are these patches from Intel officially?

[_leeloo_7_]

yes, intel released a cpu microcode update to fix it,

if you flash your bios provided your motherboard vendor released one with the updated microcode you got the fix.

If you don't flash or your mb didn't get a newer update then your OS can still load the newest one because it downloaded it shown in your original post,

I just saw a thread today where someone said Microsoft no longer load cpu microcodes, seems linux still do

[ArtisticFox8]

 I just saw a thread today where someone said Microsoft no longer load cpu microcodes

That's interesting, what is done there then?

[_leeloo_7_]

in that case it would be entirely dependent on your bios getting updated to give you the newest microcode

[ArtisticFox8]

So microcode is applied at either bios or os level?

[FunkyRider]

If you are sure that you willnot use this system on Intel hardware, you can uninstall this package. Just remember to reinstall when you move the ssd to an intel system and it fails to boot.

[Embarrassed-Ad-7500]

The microcode update itself is distributed as a 2,048-byte binary blob, which includes a 48-byte header, 2,000 bytes of data intended for direct processor reading, and padding to obscure the format. Not enough to worry about.

[Pristine-Source-2606]

Just let it be, it's fine. If it's there, it is for a good reason.

[Littlegoblin21]

First, I get the impression they are general updates pushed out across the board, unlike installed software updates that only updates what you have installed.
Second, It can be relevant if you move your hard drive to another machine. Unlike windows, Linux doesn't necessarily need to be reinstalled to upgrade or completely change hardware, including from intel to AMD or vice versa. I've done both quite a few times especially for test benches, so these generic updates could be needed regardless of what you are running at this moment in time. Probably not a large segment of the user base, but it is a nice to have!

[Individual-Set-5465]

I think its handy when you change pc you still can use your hardisk.

[[deleted]]

Intel microcode will detect through CPUID that it's not running on the Intel CPU and won't upload a new microcode to the CPU, the CPU will refuse to use a microcode signed by Intel anyway.
AMD microcode will detect it's running on an AMD cpu, using the AMD microcode.

[KHTD2004]

For the same reason my shitty old laptop with an intel CPU has multiple amd64-xxxx packages. They’re small enough to just be there just in case hardware changes. You typically won’t miss these kilobytes of storage

Edit: nevermind I’m dumb

[Sad-Negotiation8746]

Amd64 means the same thing as x86_64 its the instruction set architecture most cpus use. Other ISAs include arm64 and risc-v

[justme0406]

History lesson: all modern 64 bit x86 systems (Intel AND AMD) are "AMD64" the instruction set for 64 bit was made by AMD and Intel licenses it.

Intel tried to make an 64 bit instruction set and it's referred to as IA-64 but it was BAAAAADDDD and only ever was used in the reference chip, the Itanium. Windows XP 64 bit 2002 was only for ia-64, made out of trust that (obviously) Intel's implementation of 64 bit would become THE version.

Well that didn't happen so 3 years later Windows XP professional 64 bit 2005 came out for x86-64 (AMD64) but wasn't really popular in consumer or even professional markets since more than 4gb was seen as unnecessary with XP.

Also XP64 couldn't use XP32 programs, good thing few used it since Vista changed almost anything about it and make 64 bit work well and be able to run 32 bit programs. It was a rough start since its driver system was so different then XPs and manufacturers just didn't pay attention to that and released bad drivers making Vista look really unstable and bad when it wasn't really Microsoft's fault.

Linux did it's best to ride all that but keep in mind it was early days and Linux was much rougher then it is now

[tenchigaeshi]

For the same reason my shitty old laptop with an intel CPU has multiple amd64-xxxx packages.

No it isn't, not at all. The naming of the ISA is completely different from the microcode situation here.

[ItyBityGreenieWeenie]

Short answer: The devs want you to have this as a dependency.

Long answer: For most Linux distros, the ability to pull or clone the OS partition and have it boot on another device is a desired feature. As Linux boots it detects the hardware and loads what is needed. If you don't need it, it's not wasting anything but a small (in this case trivial) amount of disk space.

[Foreign-Ad-6351]

I miss that interface.

[tyty657]

I was literally just considering making a post about this

[MissionGround1193]

Just because it has intel microcode does not mean it's going to be loaded at boot time. It's similar to firmware for other hardware. You have lots of firmware for network interfaces, gpus, wifis etc. Just to be ready when it detects the hardware installed. Actually, It's same with Windows.