Enabled repos when installing on Debian

[KingPrawn22]

I'm installing Proxmox on top of Debian, for reasons, and have been maybe a little obsessive with making the install match the official installer as much as possible. I notice that when using the official installer that it doesn't include the 'non-free-firmware' repo, I assume because Proxmox comes with its own firmware in the 'pve-firmware' package. So when installing my Debian base I've chosen to remove this repo from it, which results in some errors in the journal about missing firmware, but the system comes up (including NIC), and after installing Proxmox I've found that all devices that previously had errors now do not, with firmware having been installed for all.

Is there actually a point in disabling the 'non-free-firmware' repo? If this was to be left as enabled when installing Proxmox, which firmware takes preference? Or, does it depend on how recent the firmware is? Could there be any conflicts? What if I installed Debian with the 'non-free-firmware' repo enabled, to prevent any potential hardware issues, but then disabled it before installing Proxmox?

I also notice that as per the 'Install Proxmox VE on Debian 12 Bookworm' guide that the 'contrib' repo is enabled. Is this necessary for Proxmox? I don't intend to install many packages on this system, trying to keep it a 'lean' Proxomox host, so if that is left enabled just to ensure users can install certain non-Proxmox related software, then I'm tempted to remove it. I have thing thing about only enabling exactly what is needed and nothing more.

Any input is greatly appreciated.

 

[LnxBil]

If this was to be left as enabled when installing Proxmox, which firmware takes preference?

The kernel is looking for its firmware on the defined locations, so the firmware in that location will be the one that is loaded. As you've already stated, Debian vanilla kernel looks somewhere different, so installed both versions will only waste space. By design both search in different locations.

Could there be any conflicts?

No, disjunct folders.

What if I installed Debian with the 'non-free-firmware' repo enabled, to prevent any potential hardware issues, but then disabled it before installing Proxmox?

Does not matter besides wasting space and potentially bandwidth and time on updates if you don't remove them afterwards.

I don't intend to install many packages on this system, trying to keep it a 'lean' Proxomox host, so if that is left enabled just to ensure users can install certain non-Proxmox related software, then I'm tempted to remove it.

The ZFS tools are in contrib, at least the Debian part of them. PVE ships their own updated packages.

 

[KingPrawn22]

The kernel is looking for its firmware on the defined locations, so the firmware in that location will be the one that is loaded. As you've already stated, Debian vanilla kernel looks somewhere different, so installed both versions will only waste space. By design both search in different locations.


No, disjunct folders.


Does not matter besides wasting space and potentially bandwidth and time on updates if you don't remove them afterwards.


The ZFS tools are in contrib, at least the Debian part of them. PVE ships their own updated packages.

Thanks @LnxBil

I'm installing Debian via a preseed, and disabling the 'non-free-firmware' isn't a trivial task (imo), and though the system did boot in my case, I'm sure it's not a recommended way to go about things. Therefore, my idea is to keep it enabled during install and then immediately remove it in preparation for installing Proxmox. Since the firmware for these devices will now be installed, even if I remove that repo before installing Proxmox, does that change anything? Would there ever be a case where the firmware provided by 'pve-firmware' takes the place of the firmware installed by 'non-free-firmware' (different versions, updated versions)? Is there actually any benefit of using the firmware provided by 'pve-firmware' over what Debian installs in the 'non-free-firmware' repo?

ZFS is actually one of the reasons I'm installing Proxmox on Debian instead of using the provided installer. I want to be absolutely certain that ZFS has no way of running on my install, so am going through the process of blacklisting the zfs module and masking any ZFS related services before installing Proxmox. Probably better not to go into the 'why' of that one. So it seems like I'm not missing anything from removing the 'contrib' repo.

 

[MarkusKo]

non-free-firmware repo is needed for intel and amd microcode, maybe not needed but could solve some issues with power management ...

 

[KingPrawn22]

non-free-firmware repo is needed for intel and amd microcode, maybe not needed but could solve some issues with power management ...

I understand that in some cases it's needed, as in absolutely required for the hardware to work, whereas in my case (AMD CPU + iGPU and Realtek NIC) I was able to boot the system without it enabled. The 'pve-firmware' contained the firmware for the devices that were complaining when I installed it. I'm just trying to better understand the differences in firmware installation between installing Proxmox using the official installer vs installing Debian and then Proxmox, and how the firmware provided by each interacts, if at all.

 

[MarkusKo]

As far as i know pve repos don't have the cpu microcode firmware included.
In pve 8.x the non-free-firmware was not enabled and cpu microcode packages had to be installed manually, in pve 9.0 beta the non-free-firmware is enabled and on a fresh install the cpu microcode is installed by default

Installation ISO

    Install the microcode package matching the current platform.

        This ensures that new Proxmox VE installations get available fixes for CPU security issues and other CPU bugs.
        Note that to get microcode updates that were released after the ISO was built, hosts have to be updated regularly.
        This also means that installations now have the non-free-firmware repository enabled.

https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.0_BETA_1

 

[KingPrawn22]

As far as i know pve repos don't have the cpu microcode firmware included.
In pve 8.x the non-free-firmware was not enabled and cpu microcode packages had to be installed manually, in pve 9.0 beta the non-free-firmware is enabled and on a fresh install the cpu microcode is installed by default

Installation ISO

    Install the microcode package matching the current platform.

        This ensures that new Proxmox VE installations get available fixes for CPU security issues and other CPU bugs.
        Note that to get microcode updates that were released after the ISO was built, hosts have to be updated regularly.
        This also means that installations now have the non-free-firmware repository enabled.

https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.0_BETA_1

Well spotted! If the 'non-free-firmware' repo is going to be added in future versions, then I'll simple leave it as it is. That makes the whole setup much simpler. Still not sure on the 'contrib' repo, but I can do more research on that myself to see whether it's best to leave that enabled or to remove it. Many thanks @MarkusKo

 

[MarkusKo]

the contrib repo is enabled in pve 9.0 too but it could be a requirement for the non-free-firmware repo

contrib packages contain DFSG-compliant software, but have dependencies not in main (possibly packaged for Debian in non-free).
Note: In this component, the package contents after installation may be considered non-free and with a non-free license,
but the package contents in the distribution repository would be DFSG compliant and, as mentioned, may get dependency contained in non-free.

from debian website

 

[KingPrawn22]

the contrib repo is enabled in pve 9.0 too but it could be a requirement for the non-free-firmware repo

contrib packages contain DFSG-compliant software, but have dependencies not in main (possibly packaged for Debian in non-free). Note: In this component, the package contents after installation may be considered non-free and with a non-free license, but the package contents in the distribution repository would be DFSG compliant and, as mentioned, may get dependency contained in non-free.

from debian website

Yeah I've looked into the official definitions of what it is, but it isn't the easiest language to understand. I assume that since the 'non-free' repo (not 'non-free-firmware) is not included in Proxmox, that it is not needed. But the above quote seems to suggest that there might be some software in the 'contrib' repo that has dependencies packaged in 'non-free', which I assume would still work even if 'non-free' isn't enabled. Whether any of this indicates whether 'contrib' is actually needed for a 'lean' Proxmox system or not is still a question I'm looking for an answer to. In regards to creating a 'production' system, I feel it's a good habit to try to remove things that are not strictly necessary, whether that's for security, efficiency etc.

 

[MarkusKo]

AMD CPU + iGPU and Realtek NIC

Even if everything seems to work, depending on your needs you may need the non-free-firmware for your iGPU if you intend to use it
at least here i can see firmware-amd-graphics* and firmware-realtek* (lan and wlan?)

But i think in your case the amd64-microcode is certainly a good idea to have installed

The contrib repo seems to be for dependencies for the non-free-firmware repo, they are most likely splitted for licensing reasons if i interpreted the text from debian correctly.

 

[proxuser77]

Whether any of this indicates whether 'contrib' is actually needed for a 'lean' Proxmox system or not is still a question I'm looking for an answer to. In regards to creating a 'production' system, I feel it's a good habit to try to remove things that are not strictly necessary, whether that's for security, efficiency etc.

@KingPrawn22 But you do realise that enabling some repository components, such as 'contrib' or 'non-free', doesn't automatically install any related packages unless they are dependencies of packages that you have explicitly installed from 'non-free' or (maybe?) the Proxmox repositories. Either way, disabling these components won't achieve much, except perhaps making the apt update command run a bit faster. ;-)

The same logic applies to ZFS, respectively the ZFS Kernel modules, although there might at least a minimal theoretical risk if modules are installed or loaded that are not actually used:

However, If you set up your Debian system with any other file system, ZFS doesn’t just get installed automatically, why would it? Sure, you can blacklist the ZFS kernel module if you really want to, but what for? If somone were to be able to gain root acces in order to install ZFS, you'd have way bigger problems than a few kernel moidules ;-)

 

[MarkusKo]

Well at least in this case zfs will be installed because if you install pve on top of debian you also have to switch to the pve kernel and that kernel includes zfs.

I personally would not go that route and use the the official installer iso. But there are always some edge cases like debian preseed install or full disk encryption ...

Btw. is debian preseed an absolute requirement or would a pve automated install be an alternative?

 

[proxuser77]

Well at least in this case zfs will be installed because if you install pve on top of debian you also have to switch to the pve kernel and that kernel includes zfs.

Well then, this whole activism (sorry) around the repo components makes even less sense, in my opinion.

Blacklisting the ZFS kernel modules, if not being used, might make sense though.

 

[LnxBil]

Would there ever be a case where the firmware provided by 'pve-firmware' takes the place of the firmware installed by 'non-free-firmware' (different versions, updated versions)?

They cannot occupy the same file, this is prohibited by the package manager.

They easiest way to go about the problem is to install PVE manually and compare the package lists after install with that of what you installed and remove everthing you don't know or don't care about.