Upcoming changes to IncusOS

News
1

Three significant changes are currently being worked on for IncusOS and will be pushed starting October 1st:

Transition to a new kernel configuration

We’re currently working on a more server-optimized kernel for use by both IncusOS and FuturFusion’s HypervisorOS. This is work led by @amikhalitsyn.

The new kernel will be optimized for more modern systems and will shed a lot of drivers for hardware that doesn’t really make sense on an IncusOS host. That will give us a lighter kernel and also a reduced attack surface.

To prevent regressions, it would be very useful for us to know what kernel modules folks are actively using on their IncusOS systems. This will let us ensure that we don’t accidentally strip any of those from the new kernel image.

IncusOS users are kindly requested to update to the current OS image, reboot and then run:

incus query /os/1.0/debug/kernel | jq '{architecture, cpu_baseline, version, modules: ([.modules[] | .name] | join(","))}'

This assumes that the jq command is present on the system.
Output will look like:

{
  "architecture": "x86_64",
  "cpu_baseline": "x86_64_v3",
  "version": "7.1.10-zabbly+",
  "modules": "9pnet,aesni_intel,autofs4,bridge,btrfs,ccp,dm_bio_prison,dm_bufio,dm_crypt,dm_multipath,dm_persistent_data,dm_verity,drm,drm_client_lib,drm_kms_helper,drm_shmem_helper,erofs,gf128mul,i2c_mux,i2c_smbus,iTCO_wdt,ib_cm,ib_core,intel_pmc_bxt,intel_rapl_common,iommufd,ip6_udp_tunnel,irqbypass,iscsi_tcp,iw_cm,kvm,kvm_amd,libahci,libblake2b,libiscsi,libiscsi_tcp,llc,lru_cache,netfs,nf_conntrack,nf_defrag_ipv4,nf_defrag_ipv6,nf_nat,nf_tables,nfnetlink,nft_chain_nat,nft_ct,nft_masq,nft_meta_bridge,nls_iso8859_1,nvme_auth,nvme_core,nvme_fabrics,nvmet,overlay,raid6_pq,rdma_cm,scsi_transport_iscsi,snd,snd_pcm,snd_timer,soundcore,spl,stp,tap,tcp_bbr,udp_tunnel,vfio,vfio_pci_core,vhost,vhost_iotlb,vhost_net,vhost_vsock,virtio_dma_buf,vmw_vsock_virtio_transport_common,vsock,x_tables,xor,zfs"
}

Use this form to submit your output: IncusOS - kernel modules

Those using clusters can use /os/1.0/debug/kernel?target=XYZ to get the data for a specific server (XYZ in this case).

Revocation of the 2025 signing key

We sign our images with a yearly signing key, switching over the signing typically with the first build of the year in January. Keys are marked as valid for two years (not that UEFI really enforces that), allowing for a transition period.

To fully rotate the key, we need to actually revoke and push a revocation entry for that key.
We are now about to do this for the first time by fully revoking the 2025 signing key.

This shouldn’t have any impact so long as everyone is on an IncusOS build from this year.

Removal of legacy migration logic

IncusOS generally expects users to update their systems (apply the OS update and reboot) at least once a month. We do keep compatibility logic for a bit longer than that but don’t generally guarantee upgrades when going more than 3 months without an OS update.

We currently have a fair bit of old upgrade logic that we’d like to get rid of, so if you’ve not updated and rebooted your IncusOS system in the past month or so, now would be a good time to do so!

3

I am not expert in kernel things, but using the debian 13 on my small dual nic based thin client.

4

Here are the results from

incus query /os/1.0/debug/kernel | jq '{architecture, cpu_baseline, version, modules: ([.modules[] | select(.in_use) | .name] | join(","))}'

for one of my systems running incusOS (though this box will be retired soon, to be replaced with a newer one)

{

  "architecture": "x86_64",
  "cpu_baseline": "x86_64_v3",
  "version": "7.1.10-zabbly+",
  "modules": "ac97_bus,aesni_intel,asus_wmi,autofs4,bluetooth,bridge,btbcm,btintel,btmtk,btrtl,cdc_ether,cec,cfg80211,crc8,dm_bufio,dm_crypt,dm_multipath,dm_verity,drm,drm_buddy,drm_client_lib,drm_display_helper,drm_exec,drm_gpusvm_helper,drm_gpuvm,drm_kms_helper,drm_suballoc_helper,drm_ttm_helper,erofs,firmware_attributes_class,gf128mul,gpu_sched,hid,hid_sensor_hub,i2c_algo_bit,i2c_mux,i2c_smbus,i915,int340x_thermal_zone,intel_ishtp,intel_pmc_ssram_telemetry,intel_rapl_common,intel_vsec,iommufd,irqbypass,kvm,libblake2b,llc,mei,mei_me,mii,mtd,nf_conntrack,nf_defrag_ipv4,nf_defrag_ipv6,nf_tables,nfnetlink,nft_ct,nft_meta_bridge,nls_iso8859_1,nvme,nvme_core,overlay,phy_package,platform_temperature_control,pmt_class,pmt_discovery,pmt_telemetry,processor_thermal_device,processor_thermal_mbox,processor_thermal_power_floor,processor_thermal_rapl,processor_thermal_rfim,processor_thermal_soc_slider,processor_thermal_wt_hint,processor_thermal_wt_req,r8152,raid6_pq,rc_core,realtek,snd,snd_compress,snd_hda_codec,snd_hda_codec_alc269,snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_codec_intelhdmi,snd_hda_codec_realtek_lib,snd_hda_core,snd_hda_ext_core,snd_hda_scodec_component,snd_hwdep,snd_intel_dspcfg,snd_intel_sdw_acpi,snd_pcm,snd_pcm_dmaengine,snd_soc_acpi,snd_soc_acpi_intel_match,snd_soc_acpi_intel_sdca_quirks,snd_soc_core,snd_soc_hda_codec,snd_soc_hdac_hda,snd_soc_sdca,snd_soc_sdw_utils,snd_sof,snd_sof_intel_hda,snd_sof_intel_hda_common,snd_sof_intel_hda_generic,snd_sof_intel_hda_mlink,snd_sof_intel_hda_sdw_bpt,snd_sof_pci,snd_sof_pci_intel_cnl,snd_sof_utils,snd_sof_xtensa_dsp,snd_timer,soundcore,soundwire_bus,soundwire_cadence,soundwire_generic_allocation,soundwire_intel,sparse_keymap,spi_intel,spl,stp,tcp_bbr,thunderbolt,ttm,typec,typec_ucsi,usbnet,vfio,vfio_pci_core,vhost,vhost_iotlb,video,vmw_vsock_virtio_transport_common,vsock,wmi,x_tables,xor,zfs"

}
5

Please use the form as we’re not going to be scanning the forum for extra output when we have the form output all landing in a spreadsheet that can be programmatically analyzed.

6

Oops sorry, will do :slight_smile:

7

When this change goes in to effect will there be a page describing what hardware (modules?) is or isn’t supported in future releases? I have been planning to deploy incus os to some 3rd party providers and I’m not yet sure what the hardware will be so can’t offer module listings.

8

If we put hard restrictions, then yeah, we’re likely to document them.
In general I expect we’ll be fine to add more modules where they make sense, the main reason for the current survey is to avoid any obvious regression at the time of the transition.

1 Like