nocloud doesn't support CIDATA with MIME multi-part user-data

[mdnix]

Bug Report

Description

I tried to run Talos on Exoscale private instances. In that case the instances don't have access to the metadata service (169.254.169.254). Due to the fact that they are private I can't use the exoscale disk image, since that one expects metadata coming from that link-local address.
Because of that I used the nocloud disk image instead. With that Exoscale falls back to using a CIDATA ISO instead which contains the user-data.

However, Talos fails to parse the user-data with:

failed to load config via platform nocloud: decode error: yaml: line 4: could not find expected ':'

The issue is that Exoscale provides the user-data as a MIME multi-part archive and the nocloud platform doesn't recognize this format and tries to parse the entire contents as YAML.

As an example this is how Exoscale provides the user-data to the machines:

Content-Type: multipart/mixed; boundary="===============OTc5MDFkZDQtMzkxOS00OWI2LWJhMjAtZGNhNGEzZjFmNjc4=="
MIME-Version: 1.0

--===============OTc5MDFkZDQtMzkxOS00OWI2LWJhMjAtZGNhNGEzZjFmNjc4==
Content-Type: text/cloud-config; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="user-data-0"
dmVyc2lvbjogdjFhbHBoYTEKZGVidWc6IGZhbHNlCnBlcn...

--===============OTc5MDFkZDQtMzkxOS00OWI2LWJhMjAtZGNhNGEzZjFmNjc4==

The actual machineconfig is base64 encoded inside one of the MIME parts.

I have a working fix that handles this MIME multi-part format. I'd be happy to submit a PR, though it still needs a bit of polishing. For now I wanted to report the issue to have it as a reference.

Logs

Errors with nocloud 1.12.1

user: warning: [2026-01-20T10:53:29.653647055Z]: [talos] downloading config {"component": "controller-runtime", "controller": "config.AcquireController", "platform": "nocloud"}
user: warning: [2026-01-20T10:53:29.756267055Z]: [talos] volume status {"component": "controller-runtime", "controller": "block.VolumeManagerController", "volume": "platform/cidata/config", "phase": "waiting -> ready", "location": "/dev/vdb"}
kern: debug: [2026-01-20T10:53:29.759089055Z]: ISO 9660 Extensions: Microsoft Joliet Level 3
kern: debug: [2026-01-20T10:53:29.759218055Z]: ISO 9660 Extensions: RRIP_1991A
user: warning: [2026-01-20T10:53:29.759264055Z]: [talos] found config disk (cidata) at /dev/vdb
user: warning: [2026-01-20T10:53:29.759934055Z]: [talos] fetching meta config from: cidata/meta-data
user: warning: [2026-01-20T10:53:29.760729055Z]: [talos] fetching network config from: cidata/network-config
user: warning: [2026-01-20T10:53:29.761454055Z]: [talos] failed to read network-config: no such file or directory
user: warning: [2026-01-20T10:53:29.762189055Z]: [talos] fetching machine config from: cidata/user-data
user: warning: [2026-01-20T10:53:29.764171055Z]: [talos] volume status {"component": "controller-runtime", "controller": "block.VolumeManagerController", "volume": "platform/cidata/config", "phase": "ready -> closed", "location": "/dev/vdb"}
user: warning: [2026-01-20T10:53:29.771281055Z]: [talos] controller failed {"component": "controller-runtime", "controller": "config.AcquireController", "error": "failed to load config via platform nocloud: decode error: yaml: line 4: could not find expected ':'"}

Success with fix which adds mime parsing to nocloud.

user: warning: [2026-01-21T14:08:04.126057033Z]: [talos] found config disk (cidata) at /dev/vdb
user: warning: [2026-01-21T14:08:04.126488033Z]: [talos] fetching meta config from: cidata/meta-data
user: warning: [2026-01-21T14:08:04.127150033Z]: [talos] fetching network config from: cidata/network-config
user: warning: [2026-01-21T14:08:04.127679033Z]: [talos] failed to read network-config: no such file or directory
user: warning: [2026-01-21T14:08:04.128185033Z]: [talos] fetching machine config from: cidata/user-data
user: warning: [2026-01-21T14:08:04.129245033Z]: [talos] volume status {"component": "controller-runtime", "controller":
"block.VolumeManagerController", "volume": "platform/cidata/config", "phase": "ready -> closed", "location": "/dev/vdb"}
user: warning: [2026-01-21T14:08:04.131139033Z]: [talos] nocloud: parsed 1 MIME parts
user: warning: [2026-01-21T14:08:04.133195033Z]: [talos] machine config loaded successfully {"component": "controller-runtime",
"controller": "config.AcquireController", "sources": ["nocloud"]}
user: warning: [2026-01-21T14:08:04.134278033Z]: [talos] task loadConfig (1/1): done, 113.216524ms
user: warning: [2026-01-21T14:08:04.134716033Z]: [talos] phase config (9/9): done, 114.412797ms
user: warning: [2026-01-21T14:08:04.135139033Z]: [talos] initialize sequence: done: 2.442343847s

Environment

• Talos version: v1.12.1
• Kubernetes version: v1.35.0
• Platform: nocloud

[sergelogvinov]

Hi, did you try to create an issue for Exoscale?
NoCloud stores raw files in ISO disk. I don’t remember that it supports the Content-Type: multipart/mixed format for files.

Probably they create the files and store them in the wrong format.

[mdnix]

Hey @sergelogvinov, thanks for having a look.
I did reach out to Exoscale but haven't heard back yet.

With public instances, accessing http://169.254.169.254/1.0/user-data gives me exactly what I provided, the raw config.
But when instead creating the machines as private instances on Exoscale, the user-data gets delivered as MIME multipart archive in the CIDATA disk. Also couldn't find anything in their docs to disable this and just pass raw.

Technically what Exoscale provides is a valid format.
However the MIME output they provide looks malformed, there is no blank line between the headers and body. So I'm a bit reluctant to submit my fix just now, since I had to add logic to normalize the malformed user-data.

It's just odd that they do it this way I haven't seen any other CSP wrap user-data like that.

[mdnix]

I just got an update from their support team. They explained that they currently use MIME to combine platform data (passwords, SSH keys) with user-provided data. They also confirm that the multi-part format is missing a blank line. Next they plan to test sending the platform data via vendor-data instead of using MIME. If this works they plan to release an updated version to fix the issue. They will share more information once they have finished testing.