Why 2 microcodes? <SOLVED>

[sleeper12]

I see Mint 19 has 2 microcodes installed, amd64 & intel. Are both needed or just one? I have a Dell 64 bit with intel cpu, so can I safely remove the amd64 microcode or not?

[trytip]

EDIT:

[sleeper12]

Yes, what?

[smurphos]

No

The most recent ubuntu kernel packages (4.15.0.-23 and later if memory serves) specify both microcode packages as dependencies, although depending on your CPU only one will actually get used. So they can't be removed without removing kernel packages.

@trytip - IIRC you are using mainline kernels? If so you wouldn't see this dependency,

[karlchen]

Hello, sleeper12.

Why 2 microcode packages? Because Ubuntu added both microcode packages, intel-microcode and amd64-microcode, to the list of dependencies in the kernel meta package kernel-image-generic.
Reason for doing so: very likely to make sure that patched microcode modules are available and can be loaded by the kernel, if needed to enable best possible protection against Spectre and Meltdown CPU flaws.
Only the module matching your CPU will be loaded either from intel-microcode or from amd64-microcode. Cf here also, please: About packages intel-microcode & amd64-microcode:

So there is no reason to be worried, just because both packages are present on the disk.
There is no good reason to remove one of the two, just because your CPU is either Intel or AMD, never both.
Do not try to resolve problems which do not exist.

Regards,
Karl

[trytip]

EDIT:

[gm10]

^ ignore him (sorry man, you are just plain wrong). What the others said above is correct. You cannot safely remove it for the most current kernels on Mint 19, and there's no harm having it.

[trytip]

EDIT:

[DAMIEN1307]

I dont know why some seem to think that the microcode cant be removed without ill affects...smurphos wrote "So they can't be removed without removing kernel packages."
...i did it almost immediately upon new install and have zero harmful affect in so doing...it did not remove kernel packages

pkg --get-selections | grep linux-headers && dpkg --get-selections | grep linux-image
linux-headers-4.15.0-22 install
linux-headers-4.15.0-22-generic install
linux-headers-4.15.0-23 install
linux-headers-4.15.0-23-generic install
linux-image-4.15.0-22-generic install
linux-image-4.15.0-23-generic install
damien@damien ~ $

...here is the proof in the pudding...my terminal command output now only shows just the intel kernel microcode left in the system whereas it previously had both...DAMIEN

damien@damien ~ $ dpkg -l | grep microcode
ii intel-microcode 3.20180703.2 amd64 Processor microcode firmware for Intel CPUs
ii iucode-tool 2.3.1-1 amd64 Intel processor microcode tool
damien@damien ~ $

[smurphos]

Code: Select all

steve@HP-Pavilion-g6-Notebook-PC:~$ uname -r
4.15.0-24-generic
steve@HP-Pavilion-g6-Notebook-PC:~$ apt remove amd64-microcode
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  intel-microcode iucode-tool
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED
  amd64-microcode linux-generic linux-image-generic
0 to upgrade, 0 to newly install, 3 to remove and 0 not to upgrade.
After this operation, 104 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

Probably not a good idea to hit Y....

[gm10]

I dont know why some seem to think that the microcode cant be removed without ill affects...

OP is asking about Mint 19, and the statement was that for kernel -23 and later the microcode is a kernel dependency (see post above for proof). An up-to-date Mint 19 system cannot safely remove a microcode package.

That microcode package you've got installed is a debian package so I'm assuming you are on LMDE or running a custom kernel. Same for post above yours, none of those kernels are relevant.

Probably not a good idea to hit Y....

I always make sure to run those "bad idea" commands for demonstration purposes with -s (simulate). I dread the thought that I might actually hit Y otherwise.

[JerryF]

...
Do not try to resolve problems which do not exist.
...

What a great statement! I'll be using this in other aspects of life, in addition to Mint!!

[DAMIEN1307]

I get my initial up to date microcodes from the university of oregon repositories in new editions of my linux mint xfce as well as my peppermint 9 systems installed here...and yes, when there is a further update after the fact, the driver manager and or the update manager keep it up to date for me...i realize that most are on the "425" microcode at the moment, but "703" is availabele to me and is compatable with my systems, therefore i have installed them though i do not recommend others to do so like i do unless they really know what they are doing...as you can see though, i have safely removed a microcode pkg. from both LM19 as well as peppermint 9...im using both as we speak and type...my boots also went from 16 sec. on old fashioned HDD to 12 to 13 seconds...i am not running any custom kernels...i use only what is available through the update manager, nothing else from the outside other than that microcode...DAMIEN

[DAMIEN1307]

Just an after thought...the only reason i can discern to have both microcodes is if one decides to swap hardrives from lets say an AMD system to an Intel system or vice versa...the kernel itself knows which CPU it is booting from and knows to pick the correct microcode during bootup and will not choose the wrong one...since i do not intend to swap back and forth to different systems from AMD to Intel, that is the only reason why i uninstalled the AMD microcode but thats just me is all...i only posted in here just to say it is possible to do, even easy to do and have done it on my 4 home systems and all work great...2 LM 19 xfce and 2 Peppermint 9s...nothing special here...DAMIEN

[gm10]

Of course it's possible to do. You can remove the microcode and, as smurphos has shown, that then removes the kernel meta packages. The only reason your system keeps getting updates is because of the poorly designed or in my opinion bugged Update Manager, which ignores meta packages and just installs whatever highest version of the individual kernel components it can find. That's the whole reason we are in this -24 mess despite that kernel having been revoked. Update Manager ignores the revocation.

That still doesn't mean it's a good idea to do so. Kernel meta packages are a good idea, and I hope Update Manager gets fixed one day. There is zero reason to uninstall a microcode package. All you gain is 32 KiB of disk space. It's ridiculous that we are even talking about it tbh. Your boot duration change must be due to something else btw.

[smurphos]

The other danger is that a week, month, two months down the line you run apt autoremove without due diligence and hey presto the microcode you do want is gone.

This is a case of leave well alone and certainly, don't encourage removal.

[sleeper12]

Ok, I'll keep both microcodes installed since it seems it does no harm. What puzzles me now is I have nvidia in driver manager, but no intel (see screenshot trytip posted). Is this a problem, am I using nvidia, intel, or both?

[Pjotr]

What puzzles me now is I have nvidia in driver manager, but no intel (see screenshot trytip posted). Is this a problem

No. It's as it should be. Driver Manager is only there for non-free proprietary drivers. The drivers for Intel are open-source and present by default.

[sleeper12]

What puzzles me now is I have nvidia in driver manager, but no intel (see screenshot trytip posted). Is this a problem

No. It's as it should be. Driver Manager is only there for non-free proprietary drivers. The drivers for Intel are open-source and present by default.

Am I understanding correctly then that both are being used?

[gm10]

What puzzles me now is I have nvidia in driver manager, but no intel (see screenshot trytip posted). Is this a problem

No. It's as it should be. Driver Manager is only there for non-free proprietary drivers. The drivers for Intel are open-source and present by default.

Am I understanding correctly then that both are being used?

No, but nvidia-settings should allow you to switch between them.