What is correct way to install ... intel-microcode ?

There's also the official Intel microcode git repo https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files

Since it seems the Proxmox/Debian intel-microcode package can take time to update. Just for funsies, for N100

BEFORE:
Code: 
root@n100p4:~# dmesg | grep microcode
[    1.322292] microcode: Current revision: 0x0000001a
[    1.322294] microcode: Updated early from: 0x0000000e

Commands:
Code: 
wget https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/main.zip
unzip main.zip
cd Intel-Linux-Processor-Microcode-Data-Files-main
cp -v intel-ucode/* /lib/firmware/intel-ucode/
update-initramfs -u
reboot

AFTER:
Code: 
root@n100p4:~# dmesg | grep microcode
[    1.331536] microcode: Current revision: 0x0000001c
[    1.331539] microcode: Updated early from: 0x0000000e
 
As you resurrected this old thread, here is one thing, that is missing in all this discussion:

The method of updating the Microcode at runtime on OS-level CANNOT work for all scenarios.
In other words:
The only real way to update Microcode in a way, so that it can work like intended, is through a BIOS update.
There are certain low-level issues, that can only be fixed, when BIOS loads the Microcode update VERY early. As a result, those specific issues can in no way be updated anymore at a later point in time. And from experience, nearly every platform has these kind of issues.

Don't misunderstand:
The update on OS-level is nice and dandy, as long as it really works in your specific case. However, as I explained above, there are scenarios, where it technically simply cannot help.
 
 
if anybody, like me also had problems with install intel-microcode during pve9 upgrade here a solution:

under /etc/apt/sources.list.d create a file called non-free.list with this conten:

Code: 
deb https://deb.debian.org/debian bookworm main non-free-firmware

after save and exit, make apt update && apt install intel-microcode -y
 
skraw said:
Thank you for resurrection. Why can't the wiki state where exactly the "non-free-firmware" has to be added (for non-debianists) ?
Click to expand...

It does, unless I'm misinterpreting what you mean. The wiki states
To be able to install packages from this component, run editor /etc/apt/sources.list, append non-free-firmware to the end of each .debian.org repository line and run apt update.

If you upgraded your Proxmox VE 9 install from a previous version of Proxmox VE and have modernized your package repositories to the new deb822-style, you will need to adapt /etc/apt/sources.list.d/debian.sources instead. Run editor /etc/apt/sources.list.d/debian.sources and add non-free-firmware to the lines starting with Components: of each stanza.
Click to expand...
Or is there some other information you're missing from the wiki?
 
The thing is: on my side adding it on every entry with debian.org did not work correctly. But when I added it only on the first occurrence (just like example above) it did work.
 
there is no good way for me to reproduce that situation, as I already converted the setup to 9 and turned the list files into sources as recommended. Since this was the primary intent I only tried to follow the messages from pve8to9 as close as possible, which brought me here.
 
Last edited:
It seems to be there are instructions for converted source lists and old ones. E.g. the file debian.sources contains after conversion
Code: 
# Modernized from /etc/apt/sources.list
Types: deb
URIs: http://ftp.nl.debian.org/debian/
Suites: trixie
Components: main contrib
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# Modernized from /etc/apt/sources.list
Types: deb
URIs: http://ftp.nl.debian.org/debian/
Suites: trixie-updates
Components: main contrib
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# Modernized from /etc/apt/sources.list
Types: deb
URIs: http://security.debian.org/
Suites: trixie-security
Components: main contrib
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

So I suspect I need to change the middle one to
Code: 
# Modernized from /etc/apt/sources.list
Types: deb
URIs: http://ftp.nl.debian.org/debian/
Suites: trixie-updates
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Or I add a new file that isn't overwritten by future proxmox updates, called for instance local.sources containing
Code: 
Types: deb
URIs: http://ftp.nl.debian.org/debian/
Suites: trixie-updates
Components: non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Correct?

(Actually, I updated the BIOS of my system which updated the microcode to the current latest version, so the intel-microcode is no more than a fallback)

P.S. I would say that having non-free-firmware standard in the Proxmox sources files would be a good idea. It still would require an administrator to actually install non-free-license firmware explicitly but makes it simpler to do.
 
Last edited:
gctwnl said:
So I suspect I need to change the middle one to
Click to expand...
That would basically work, albeit it would be also better to enable the non-free-firmware repo also for the main and the security repo, not just the update one. As then, you ensure you get important updates faster and major updates go smoothly.
gctwnl said:
Or I add a new file that isn't overwritten by future proxmox updates, called for instance local.sources containing
Click to expand...
That's not really correct and should give you a warning from apt due to the same repo being configured twice.

So I'd go for the first variant, but you can merge the entries where the URIs and Components match and that are signed by the same release key(ring), i.e. where just the suites differs.

In your case your debian.sources file then would look like:
Code: 
Types: deb
URIs: http://ftp.nl.debian.org/debian/
Suites: trixie trixie-updates
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://security.debian.org/
Suites: trixie-security
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

I.e., trixie and trixie-updates merged into one, the trixie-security one kept separate as it's handled by a separate infra/team and thus has its own URI.
 
Last edited:
  • Like
Reactions: gctwnl
gctwnl said:
P.S. I would say that having non-free-firmware standard in the Proxmox sources files would be a good idea. It still would require an administrator to actually install non-free-license firmware explicitly but makes it simpler to do.
Click to expand...
That actually is the case since Proxmox VE 9.0 for new installations using our official ISO image.
 
  • Like
Reactions: gctwnl
t.lamprecht said:
That actually is the case since Proxmox VE 9.0 for new installations using our official ISO image.
Click to expand...
I see. Thank you for both answers.

I did the 8 to 9 upgrade and the conversion, but to get to a real v9 setup you need to change this by hand afterwards. Maybe this is a good addition for the instructions? Or did I miss something during the (very smooth I must say) uprrade process?
 
gctwnl said:
I did the 8 to 9 upgrade and the conversion, but to get to a real v9 setup you need to change this by hand afterwards.
Click to expand...
Yes, because neither Proxmox nor Debian ever automatically changes existing APT source lists. Upgrading to a new major relesase of Proxmox and Debian is always a manual process where the user has to manually change the entries to the new release name, bookworm to trixie in this case. The same goes for adding/removing additional repos like non-free-firmware.

Also, the modernize-sources tool, which is not specific to Proxmox btw, doesen't change or add anything either; it simply converts the existing entries in the sources.list to the new format and stores them in a new file under /etc/apt/sources.list.d/

Long story short: if non-free-firmware was not already present before the upgrade and modernization steps, you still have to add it manually.
 
Last edited:
proxuser77 said:
[...]

Long story short: if contrib and non-free-firmware were not already present before the upgrade and modernization steps, you still have to add them manually.
Click to expand...
Sure. But my point was that if this is necessarily a manual intervention, it might be a good addition for the manual.
 
gctwnl said:
Sure. But my point was that if this is necessarily a manual intervention
Click to expand...
Yes, but non-free firmware is still optional and not an absolute necessity for everyone, and many people who didn't use it before the upgrade probably still aren't using it afterwards. So, if anything, this is only indirectly related to the upgrade process. ;)

But yeah, I guess, it wouldn't hurt to mention it in the upgrade instructions :)
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back