Unable to install IncusOS : "ERROR interface 0 has no MAC address" (Intel i219-LM)

hereisjames · March 29, 2026, 8:49pm

I’m not having a good time trying to migrate a working Ubuntu 24.04.4 Incus host over to IncusOS, and I would like some guidance as to whether this is user stupidity or an actual bug.

Lenovo P350 (11th Gen i5-11500)
Onboard NIC: Intel Corporation Ethernet Connection (14) I219-LM (eno1)
Add-in NIC: Realtek Semiconductor Device 8127 10GbE (enp1s0)
OS: IncusOS 202603240012

After a lot of revising of YAML eventually the IncusOS installation worked, but now incus-osd.service continuously crashes and restarts (with Ninja-like reflexes I captured) :

INFO System is starting up machine-id=...
INFO Bringing up the network
ERROR interface 0 has no MAC address

And that’s all she wrote. I’ve tried using hwaddr and this doesn’t help.

I know via the emergency screen from previous failed installs the IncusOS installer sees the i219-LM (and RTL-8127) controller perfectly fine on the PCIe bus.

I’ve seen some posts online about the e1000e driver having race conditions with the Intel Management Engine (AMT) or aggressive PCIe ASPM polling causing driver probe timeouts on Lenovo hardware. I’ve tried turning off the Intel ME/AMT but no improvement, and I’m not willing to turn off ASPM given UK power prices plus I want to retain the physical separation of management and instance networks. And it’s not like the i219-LM is unknown hardware, it should work.

So I have questions :

Is this failure to read the i219-LM MAC address a known issue with IncusOS?
Anything I can try to fix this?

I’ve done the wipe-and-reinstall dance seven or eight times trying to troubleshoot this and other problems, so I’m pretty invested in the sunk cost fallacy at this point.

Some feedback so far (I know a few of these are being worked on) :

Some sort of syntax/linting check of the preseed files would be terrific. Especially given the points below.
Having to rebuild the install USB every time you run it is painful, especially if you are working through errors in the preseed or hardware compatability. If the partition the preseed goes on was writeable by a Windows machine, or could be added via the IncusOS image downloader, people would have more flexibility in the editing workflow.
In the same vein, the preseed files are tiny, is there really no scope to add them dynamically to the image downloader (after linting)?
Having to wipe the system disk from a Linux live USB each time you reinstall IncusOS is soul destroying after a while, especially when it could be as small a mistake as not intercepting the UEFI BIOS boot in time to change the Secure Boot status, or the sort of hardware recognition issue I ran into here.
Imagine - and this is a totally just a fictitious example - you had a user whose main PC is upstairs and their headless test server is downstairs. Imagine having to physically swap the IncusOS install USB between another spare server and the test server and back again every time you needed to rewrite the USB, and every time you need to eject it to complete booting the OS, going downstairs and then upstairs each time you do. Imagine making a total of seven boot USBs.
Some small indication the Incus boot is progressing after the “IncusOS is installing …” would be welcome.
I probably missed it but I didn’t see in the documentation that you can use wildcards for the disk target - I read it in a comment here. That would have saved time vs having to boot a Linux Live USB.
A few more examples of the preseed files would have been helpful for me, particularly for the network.yaml since the syntax is quite different from both Incus itself and Netplan, plus the basic concepts are quite different.
When trying to install over a previous IncusOS install the error message from the installer is unhelpful - it says it couldn’t find the specified disk, I wasted quite a few hours pointlessly trying to fix that problem at a hardware level.
I have a lot more pain points, but I accept a number of those were self inflicted.

Any guidance or ideas would be really appreciated because I’m at the end of my rope here.

stgraber · March 29, 2026, 10:05pm

We support reading the seed from a secondary USB stick with a FAT partition labeled as SEED_DATA or equivalent ISO if using a cd-rom drive.

stgraber · March 29, 2026, 10:06pm

They are unpacked within the relevant structs, so bad typing will trigger an error, but then knowing exactly what setting is required vs not and what values are valid for each isn’t something we really want to have to put in the image customizer.

stgraber · March 29, 2026, 10:08pm

We do say This is a (potentially partial) value (as seen in /dev/disk/by-id). The value must match exactly one drive., not the “potentially partial”

stgraber · March 29, 2026, 10:09pm

Yeah, the network reference could do with more examples. Having to go read the API struct isn’t too user friendly

stgraber · March 29, 2026, 10:09pm

Hmm, that should have been improved recently, with @gibmat’s recent work.

stgraber · March 29, 2026, 10:11pm

No known issue on our end.

The has no MAC address sounds like an empty hwaddr value in the seed, but then I’d have expected it to fail at a different spot. It shouldn’t have made it to the state file.

stgraber · March 29, 2026, 10:12pm

Can you share your seed files?

hereisjames · March 29, 2026, 10:56pm

As I said, I did try using hwaddr but that failed as well. I got an exciting ERROR timed out waiting for udev to rename interface(s).

hereisjames · March 29, 2026, 11:21pm

I’m not saying these are in any way sensible; I got pretty desperate for the last couple of rounds and I am not a developer.

install.yaml :
force_install: true
target:
id: “ata-Patriot_P210_128GB_P210EBBB210928070708”

incus.yaml :

apply_defaults: false
preseed:
  config:
    core.https_address: “[::]:8443”
    core.trust_password: “far2wired”
    oidc.issuer: “https://oauth.somewhere.com/”
    oidc.client.id: “areallylongsequence”
    oidc.scopes: “openid,email,profile”
    acme.agree_tos: “true”
    acme.domain: “server.domain.com”
    acme.email: “me@domain.com”
    acme.challenge: “DNS-01”
    acme.provider: “cloudflare”
    acme.dns_nameservers: “1.1.1.1:53,1.0.0.1:53”
    acme.provider.environment: |-
      CLOUDFLARE_DNS_API_TOKEN=cfut_woooooooooooooooooooooooooooooooooooooow

  networks: []

  storage_pools:
    - name: incus-store
      driver: zfs
      config:
        source: incus-store
        zfs.pool_name: incus-store

  storage_volumes: []


  profiles:
    - name: all-interfaces
      description: All interface profile
      config: {}
      devices:
        eth0:
          name: eth0
          network: eno1
          type: nic
        eth1:
          name: eth1
          network: vlan10
          type: nic
        eth2:
          name: eth2
          network: vlan20
          type: nic
        eth3:
          name: eth3
          network: vlan30
          type: nic
        eth4:
          name: eth4
          network: vlan40
          type: nic
[ ... etc ...]

network.yaml :

dns:
  hostname: "server"
  domain: "domain.com"
  nameservers:
    - "10.1.t.x"
    - "10.1.u.y"

interfaces:
  - name: "eno1"
    addresses:
      - "10.1.j.c/24"
    routes:
      - to: "0.0.0.0/0"
        via: "10.1.h.b"
    roles:
      - "management"
      - "instances"

  - name: "enp1s0"
    roles:
      - "management"
      - "instances"

vlans:
  - name: "vlan10"
    parent: "enp1s0"
    id: 10
    addresses:
      - "10.1.y.a/24"
    roles:
      - "management"
      - "instances"

  - name: "vlan20"
    parent: "enp1s0"
    id: 20
    addresses:
      - "10.1.z.a/24"
    roles:
      - "management"
      - "instances"

  - name: "vlan30"
    parent: "eno1"
    id: 30
    roles:
      - "instances"

  - name: "vlan40"
    parent: "eno1"
    id: 40
    roles:
      - "instances"

stgraber · March 29, 2026, 11:30pm

Okay, so yeah, the network config is wrong.

You need a hwaddr key on both those interfaces. You can either put the current MAC address for the NIC in there or you can put the NIC name and IncusOS will substitute it for the MAC on first boot.

The name property you can set to anything you want, it’s not used to detect the NIC, just to name the resulting bridge we’ll be creating.

hereisjames · March 29, 2026, 11:31pm

Yes, I saw you can use another stick. Writing the sda2 partition with a new seed isn’t the main issue though since that’s very fast; the issue for me was that when you boot the install USB it seems it gets written to with new partitions and I found it can’t be re-used. So I have to write the whole install CD again from the .img every time.

hereisjames · March 29, 2026, 11:38pm

I also tried something like this (I don’t have the file any more) but got “ERROR timed out waiting for udev to rename interface(s)."

dns:
hostname: "server"
domain: "domain.com"
nameservers:
- "10.1.a.g"
- "10.1.b.h"
interfaces:
- name: "core0"
hwaddr: "90:ee:26:c5:38:ef"
addresses:
- "10.1.a.z/24"
routes:
- to: "0.0.0.0/0"
via: "10.1.x.y"
roles:
- "management"
- "instances"
vlans:
- name: "vlan30"
parent: "core0"
id: 30
addresses:
- "10.1.a.b/24"
roles:
- "instances"
- name: "vlan40"
parent: "core0"
id: 40
addresses:
- "10.1.40.30/24"
roles:
- "instances"

Yeah I dunno why I’m obscuring RFC1918 space either, but here we are.

stgraber · March 29, 2026, 11:42pm

That should have worked, though you can also do:

interfaces:
  - name: "core0"
    hwaddr: "eno1"
    addresses:
      - "10.1.a.z/24"
    routes:
      - to: "0.0.0.0/0"
        via: "10.1.x.y"
    roles:
      - "management"
      - "instances"

hereisjames · March 29, 2026, 11:57pm

I wonder what triggered the udev error then.

But thanks for the other pointers, I really was on the wrong track.