Attempting to build 1.5.0 cloudinit from docs

[tangent]

I am trying to build a cloud-init version of 1.5.0.

So following this
https://docs.vyos.io/en/latest/automation/cloud-init.html#generate-qcow-image

I went and downloaded the rolling release of 1.5.0,

then built and ran a docker image with --privileged set ad described in the docs.

docker build --tag vyos-vm-images:latest -f ./Dockerfile .

docker run --rm -it --privileged -v $(pwd):/vm-build -v $(pwd)/images:/images -w /vm-build vyos-vm-images:latest bash

git clone https://github.com/vyos/vyos-vm-images.git && cd vyos-vm-images

I will note that vyos-vm-images is marked deprecated in gitlab with no note as to why in gitlab or the docs.

Attempting to run the command:
ansible-playbook qemu.yml -e disk_size=10 -e iso_local=/tmp/vyos-1.5-rolling-202409060006-generic-amd64.iso -e grub_console=serial -e vyos_version=1.5.0 -e cloud_init=true -e cloud_init_ds=NoCloud -e enable_ssh=true -e guest_agent=qemu

results in:

TASK [mount-iso : Mount squashfs image from ISO] ********************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Error mounting /mnt/cdsquash: mount: /mnt/cdsquash: failed to setup loop device for /mnt/cdrom/live/filesystem.squashfs.\n"}

in the ansible logs. Is there a flag missing on the docker command, or some other requirement that I am missing?

Thanks!

[fernando]

Thanks for sharing, unfortunately this documentation is not updated, we introduced a new builder system which should be used to build iso image. here’s the explanation how it works:

Introducing the image build flavor system

only iso is available for the moment.

[tangent]

Thank for the reply,

The ISO only part is a bit confusing still, does that mean the entire “Image format” section isn’t valid?

I was initially planning on building a qcow2 so I could cloudinit, but could replace that by setting default_config in the build, maybe. Maybe I can convert afterwards as an additional step out of band?

[greenman1969]

I think I’m trying to do the same thing. I can get to the point of a qcow2 image with cloud-init installed, but it isn’t configured to use nocloud until I’ve booted the image and ran a “dpkg-reconfigure noninteractive cloud-init” and reset cloud-init. I gotten this far by creating a custom flavor containing the below:

image_format = "qcow2"

packages = ["qemu-guest-agent", "cloud-init"]

[[includes_chroot]]
path = "etc/cloud/cloud.cfg.d/90_dpkg.cfg"
data = "datasource_list: [ NoCloud ]"

The only part I don’t know how to do is dpkg-reconfigure in the build script once the confg file is there.

[MPStudyly]

I’m doing the same thing and came this as far as you.

Can anyone from the VyOS team shed some light on this? As the provided precompiled ISOs still work flawlessly with cloud-init, there must be a way to get this working via flavor config.

We mainly rely on cloud-init working, as our whole infrastructure setup is built around it. We just recently had to move to custom builds due to the removal of all guest-agents. Firstly expecting the manual build to not pose that much of an issue, but the lacking docs about customisation are turning this into a very unpleasant experience.

[blex]

Hello,

I try to build Version 1.4.1 with cloud-init. From the download section I have the ISO for 1.4.1 downloaded.

I have also first tryed the old repostiory. Everything is working fine in there until it came to the install clout init since there is a apt source reverence that is not public

> E: The repository 'https://packages.vyos.net/releases/sagitta/1.4.1/20241206 bookworm InRelease' is not signed.\nE: Failed to fetch https://packages.vyos.net/releases/sagitta/1.4.1/20241206/dists/bookworm/InRelease 403 Forbidden [IP: 104.21.38.158 443]\nE: The repository

In the new documentation I can not find anything about cloud-init.

So could please someone form the dev team write up how to get the cloud-initd image. In the old Ansible version there have been some clous on how to run the dpkg-reconfig cloud-init, is this helps the other posters.

[blex]

To shine some lite here and spread some infos.

If you get the qcow2 Image for LTS and use it with proxmox use CAN use the cloud-init funktion of proxmox so set ips on the interface and set the password of the user.
What does not work is run the cloud-init a second time with another IP. The old IP will stay on the interface and only the new one will be added.

However, the image is Missins the qemu-agent and I couldn’t install it with

sudo su -
apt update && apt install qmeu-guest-agent

So the image generatin is still a issue.

[MPStudyly]

It was never claimed cloud-init was removed from the official builds, it was just about the guest agents (as there are/were multiple, while at most one is required).

I did some investigation as well, but I’m not fully through with this yet. First of all, @greenman1969 you can do custom hooks by adding them in the hooks/live folder. Everything that’s there will be considered when building the image. This way I was able to get dpkg-reconfigure to be run, BUT apparently thats not enough yet. Important: I only considered the workflow of directly generating .qcow2 files and use them instead of the resulting .iso, so it might already be enough, if you install manually from the .iso. Anyway, with the qcow2 mounted to the VM, cloud-init fails on first boot as it is unable to locate the default config at /opt/vyatta/etc/config.boot.default. It still manages to setup this default config, so you are able to log in using the default credentials. If you then only reset cloud-init (no dpkg-reconfigure) and reboot, it will successfully run through. Analyzing further, the leftover chroot dir in the build folder does indeed miss a copy of the default config at that location. The only one present in the chroot is found at /usr/share/vyos. Also, there seems to be no copy task to put the default config to /opt/... besides in the Dockerfile of docker-vyos, but I don’t know at what stage this is supposed to happen, if it happens after all and if it is even relevant. I’ll report back when I have more information.

[MPStudyly]

Ok, after tinkering the whole afternoon, I found a cleanish clean way to get it running with the current state of vyos_build. To get this fully polished, a PR is needed to add some missing functionality to the build process and the docs. I’ll try to work on that ASAP.

So how did I do it? The path laid in my previous post is still mostly valid. I found some workarounds easing the setup a little though. I’ll post the important bits from my custom flavor toml. This is fully self contained, no further modifications to other files in the build system are necessary.

packages = ["cloud-init"]

default_config = "interfaces {\n    loopback lo {\n    }\n}\nsystem {\n    config-management {\n        commit-revisions \"100\"\n    }\n    conntrack {\n        modules {\n            ftp\n            h323\n            nfs\n            pptp\n            sip\n            sqlnet\n            tftp\n        }\n    }\n    console {\n        device ttyS0 {\n            speed \"115200\"\n        }\n    }\n    host-name \"vyos-studyly\"\n    login {\n        user vyos {\n            authentication {\n                encrypted-password \"$6$QxPS.uk6mfo$9QBSo8u1FkH16gMyAVhus6fU3LOzvLR9Z9.82m3tiHFAxTtIkhaZSWssSgzt4v4dGAL8rhVQxTg0oAG9/q11h/\"\n                plaintext-password \"\"\n            }\n        }\n    }\n    syslog {\n        local {\n            facility all {\n                level \"info\"\n            }\n            facility local7 {\n                level \"debug\"\n            }\n        }\n    }\n}"

[[includes_chroot]]
path = "etc/cloud/cloud.cfg.d/90_dpkg.cfg"
data = "datasource_list: [NoCloud]"

[[includes_chroot]]
path = "../hooks/live/90-cloud-init.chroot"
data = "#!/bin/sh\n\necho I: Initialize cloud-init.\ndpkg-reconfigure -f noninteractive cloud-init"

That’s it. Build whatever image type you like with this and you will get an image with working cloud-init, seemingly behaving identically to the prebuild images.

To elaborate a litte on this: The second [[includes_chroot]] statement is a hacky workaround to create a hook via the flavor toml. It works as this is basically just “write data to path” where path is relative and points to the hooks directory (see EDIT2). Besides that, an actual default_config is required as apparently there is no implicit default present. This is strange, as a valid config is required to ensure the file cloud-init is looking for at /opt/vyatta/etc/config.boot.default is actually present and subsequently being migrated properly as well. I assume this issue was overlooked, as even without default_config a, besides cloud-init, generally working image is build.
Note that I took the default config from the official rolling builds and stripped the NTP config, as I don’t need that for my setup. Please adjust to your liking!

Have a nice one!

EDIT: I’m unsure if the explicit call to dpkg-reconfigure is even required. I’ll give it a shot without and will adjust my post accordingly.

EDIT2: Just as I suspected, the explicit call to dpkg-reconfigure for cloud-init is superfluous, it works the same without it. So there is no need for custom hooks to get this running. I’ll look forward opening a PR for custom hooks regardless, as there might be other software requiring it.