This message was deleted.

You're building the new media with an endpoint?

Yup. I create an endpoint, change the password, then select iso and the version I want, click build media followed by download some seconds later

It might be that the endpoint yaml is somehow misconfigured. Can you post a sanitized version of it in a code block or snippet here?

apiVersion: elemental.cattle.io/v1beta1
kind: MachineRegistration
metadata:
  creationTimestamp: "2025-01-08T15:38:15Z"
  generation: 2
  name: test3
  namespace: fleet-default
  resourceVersion: "10612717"
  uid: e5c99935-2ea4-4567-8461-535bfd7d1fc9
spec:
  config:
    cloud-config:
      users:
      - name: root
        passwd: topsecret
    elemental:
      install:
        device-selector:
        - key: Name
          operator: In
          values:
          - /dev/sda
          - /dev/vda
          - /dev/nvme0
        - key: Size
          operator: Gt
          values:
          - 25Gi
        reboot: true
        snapshotter:
          type: btrfs
      reset:
        reboot: true
        reset-oem: true
        reset-persistent: true
status:
  conditions:
  - lastTransitionTime: "2025-01-08T15:38:15Z"
    message: ""
    reason: SuccessfullyCreated
    status: "True"
    type: Ready
  registrationToken: 766ffqkn***hrdsp99b
  registrationURL: <https://rancher.domain.tld/elemental/registration/766ffqkn***hrdsp99b>
  serviceAccountRef:
    kind: ServiceAccount
    name: test3
    namespace: fleet-default

(url redacted)

might want to pull that

registrationToken

too.

Comes prefilled

So you should be able to download the config file, and mount the iso locally and verify that it exists

alright, gonna try that

Outside of that, you can manually make the iso with your config file if the operator is fail-harding at it for some reason.

there's a file

iso-config/cloud-config.yaml

in that image, but it's empty

that's the problem, but why it's not putting it in there like it's suppose to while you're building the image, I couldn't say.

comparing that with another older image I build with unmodified config, it looks the same

A next step would be to delete all your local files, clear cookies and cache and try to rebuild it and see if you still hit the issue, which at that point would be a bug.

👍

re-installing the elemental operator might provide a fix for it? Otherwise building a custom one would be a workaround until the bug gets resolved.

and built by the operator?

I'm on Rancher 2.9.4 and it's on 1.6.5 and we're not having any issues for building isos.

2.10.1 and elemental 3.0.0

¯\_(ツ)_/¯

anyways, thank you for checking 🙇‍♂️

You could check for updates for elemental and the elemental-operator

seems to be current. The installation is kinda fresh as well, from around christmas

good luck!

Thank you 🙂

3.0.0

should be the UI Extension version, but I assume elemental-operator

1.6.5

is installed

yup

does the elemental-operator pod have any error logs?

haven't seen any, I can check more thoroughly in 2 hours, after I finished that meeting marathon

even though this should fail at installation, it should not install the machine correctly from the bootable iso

it installs fine, issue appears on boot afterwards

the

/etc/rancher/elemental/agent/config.yaml

should have been set by the

/oem/elemental-system-agent.yaml

yip configuration, I would also check if this file exists (it should if installation succeded), assuming you can access the machine somehow

I checked from grub, it does not exist in the broken version. Need to check in the working version

sorry, possibly it will be something like

/oem/9x_custom.yaml

will check 👍

it would also help to have the installation logs when it fails, you can prevent the machine from rebooting configuring

MachineRegistration.spec.config.elemental.install.reboot: false

so you have the time to check the

elemental-system-agent.service

logs

roger. Assuming changing that config doesn't cause the same issue.

my bad, it's

elemental-register-install.service

I watched that one in both installs, looks exactly the same

if you can reproduce I hope you have some pointers to investigate, for example by checking the installation logs before the machine reboots

Yup. Currently poking around. Changing the config, building new images, trying again. I need to know what happened yesterday to gain some more confidence in this

I encountered this issue today and after many rebuilds I could confirm that in my case it was triggered by a cloud-config that is not within the yip-supported subset (list of lists for

runcmd

). I could also not find a relatable error in the image's

build

pod.

I've found this issue yesterday...

@worried-waiter-10876 it is possible that if the cloud-init syntax is not supported, the

elemental-setup-boot.service

running on the installed machine is going to fail, preventing correct initialization. This is where I expect to see the errors, assuming you can still access the logs. Also note that you do have the option to use the yip syntax instead. Which we do support everywhere you can enter a

cloud-config

. https://elemental.docs.rancher.com/cloud-config-reference

Yes. In fact I was able to confirm that the syntax I used is unsupported by reading through the yip source code. I was not able to access the logs because yip would have been the one who sets up access to the machine.. Is there any documentation on the yip syntax other than examples? In any case, we would need to make sure that such errors are caught at Seed Image creation already!