Autoinstalling ubuntu-server 20.04.3 from the live-iso

Make sure to file a PR to our templates if you spot a bug. THanks!

@ncstate-mafields ,

I have been able to make it work for UEFI systems by having this in my PXEGrub2 template:

Note, this is still with the solution I have worked out on our bootstrap system, so pobably some variables needs to be changed.

menuentry "Install Ubuntu Server <%= @host.operatingsystem.release_name %>" {
    set gfxpayload=keep
    linux ubuntu/<%= @host.operatingsystem.release_name %>/vmlinuz ip=dhcp url=http://<%= @preseed_server %><%= @preseed_path %> autoinstall ds=nocloud-net\;s=http://<%= @preseed_server %>/pub/preseed/autoinstall/<%= @host.shortname %>/ root=/dev/ram0 ramdisk_size=1500000 fsck.mode=skip
    initrd ubuntu/<%= @host.operatingsystem.release_name %>/initrd

As you can see it contains the extra line “set gfxpayload=keep”, and the line starting with linux does not contain “cloud-config-url=/dev/null”.

Hope this will help you further.


I’ve ensured my template points to ds=nocloud-net;s=http://<%= @preseed_server %>/pub/preseed/autoinstall/<%= @host.shortname %>/ and created the pub directory on my foreman server as I do not have katello installed.

However I still do not see the <host.shortname> with userdata being generated in the pub directory. Should I be able to generate the userdata file without Katello installed?

Many Thanks,

@tania ,
This is indeed the part which is not yet available to be created by forman (we are still running foreman 3.2/katello 4.4)>
In order to have these files, I copy the content of the provisioning-template (which you can view from the host) into th efile user-data.
The file meta-data alsways contains the same content.


Thank you for the response. I figured I could copy and paste the user-data and that works fine, however with potentially 100 machines to build in a year, this would be rather labour intensive. Do you know if it is planned to introduce this functionality with just foreman?

Many Thanks,

i wonder how you all succeeded with having the finish script download and execution in the “user-data”/“runcmd” section as it is delivered in the templates with Foreman 3.3. I had install loops, since it was not executed before the reboot. I shifted it to the “late-commands” section with “curtin in-target” prefixes.
Am i the only one? Is my setup so special?

@langesmalle @tania The static userdata endpoint in the pub directory shouldn’t be necessary in Foremen 3.2.

It is capable of the API endpoint. So, you can create a userdata template according to the current upstream template (see here). Then, you have to associate the template with the corresponding operating system first and choose the template in that operating system configuration afterwards.

You can see in this post how the PXELinux (similar for UEFI) template can then point to the corresponding address.

Does this help you/make it easier to configure?

Hey @timdeluxe!

No, your setup is probably not so special. I did also struggle with the runcmd section - does it work when you shift the section to curtin in-target?

I’m deploying hosts with the latest version of the template without any problems. You can see it here. You gotta pay attention to change the download directory to /target/tmp/ when using the in-target commands afterwards.

@ncstate-mafields regarding your issue with the missing network identifier:

My issue turned out to be a missing interface identifier in Foreman, which was causing the user-data YAML to be invalid:

I’ve currently this PR open which originated from @acittlau’s post here. It implements a MAC-based network device assignment which is more reliable.

No, it doesn’t work when shifting to curtin in-target in the user-data/runcmd section, it just runs too late.
However as you pointed out, it is already fixed in the latest templates, so no action like a PR required anymore. Didn’t see that yet.
And yes, i payed attention about /target/.... Thanks for pointing out, that it is already fixed in the code.

1 Like


Going down the 22.04 rabiit hole here. I have a setup with server and proxy.

Did the installation_media under pub, and the installation media part works. Also enabled trusted proxy on server.

Now I am puzzled to make the meta-data template fetch to work.

If I set the IPv4 Address when declaring the host, I can manage to get the meta-data rendered template using this “s=” URL:

Pointing to the server (WORKING):


Logs (server):

2022-09-02T09:04:32 [I|app|36815f54] Started GET "/userdata/meta-data" for x.x.x.x at 2022-09-02 09:04:32 -0400
2022-09-02T09:04:32 [I|app|36815f54] Processing by UserdataController#metadata as TEXT
2022-09-02T09:04:32 [I|app|36815f54]   Rendered text template (Duration: 0.0ms | Allocations: 1)
2022-09-02T09:04:32 [I|app|36815f54] Completed 200 OK in 11ms (Views: 0.4ms | ActiveRecord: 2.8ms | Allocations: 2978)

Pointing to the proxy (WORKING):


Logs (proxy):

2022-09-02T09:08:31 ab276f83 [I] Started GET /userdata/meta-data 
2022-09-02T09:08:31 ab276f83 [I] Finished GET /userdata/meta-data with 200 (30.0 ms)

Logs (server):

2022-09-02T09:08:31 [I|app|50ba107b] Started GET "/userdata/meta-data?" for x.x.x.x at 2022-09-02 09:08:31 -0400
2022-09-02T09:08:31 [I|app|50ba107b] Processing by UserdataController#metadata as TEXT
2022-09-02T09:08:31 [I|app|50ba107b]   Parameters: {"url"=>"", "userdatum"=>{}}
2022-09-02T09:08:31 [I|app|50ba107b]   Rendered text template (Duration: 0.0ms | Allocations: 1)
2022-09-02T09:08:31 [I|app|50ba107b] Completed 200 OK in 10ms (Views: 0.3ms | ActiveRecord: 2.7ms | Allocations: 2962)

So that tells me it is possible to fetch if from the proxy.

But if I remove the IPv4 Address in the host definition (I’d like to keep it MAC only), I can get it work work to the server but not via the proxy:

Pointing to the server (WORKING):

ds=nocloud-net;s=<%= @host.mac %>/

Logs (server):

2022-09-02T09:14:41 [I|app|1e9cf0e9] Started GET “/userdata/00:50:56:b0:95:09/meta-data” for x.x.x.x at 2022-09-02 09:14:41 -0400
2022-09-02T09:14:41 [I|app|1e9cf0e9] Processing by UserdataController#metadata as TEXT
2022-09-02T09:14:41 [I|app|1e9cf0e9] Parameters: {“mac”=>“00:50:56:b0:95:09”}
2022-09-02T09:14:41 [I|app|1e9cf0e9] Rendered text template (Duration: 0.0ms | Allocations: 1)
2022-09-02T09:14:41 [I|app|1e9cf0e9] Completed 200 OK in 22ms (Views: 0.4ms | ActiveRecord: 9.2ms | Allocations: 6998)

Pointing to the proxy (NOT WORKING):

ds=nocloud-net;s=<%= @host.mac %>/

Logs (proxy):

2022-09-02T09:18:27 bcd693a1 [I] Started GET /userdata/00:50:56:b0:95:09/meta-data 
2022-09-02T09:18:27 bcd693a1 [I] Finished GET /userdata/00:50:56:b0:95:09/meta-data with 404 (0.53 ms)

Logs (server):
nothing at all...

Looks like the proxy doesn’t forward to the server when adding the mac in the directory.

Am I doing something wrong to assume it should work from the proxy using the MAC in the path?

Or should I open an issue?

Thanks for the help!

Hey! I’m actually kinda wondering, that your MAC-based request works in the first place. I thought the rendering of the user-data template is completely IP-based. So, you might create an issue for this.

Still, I’d like to know why the meta-data is so important for you? AFAIK only the user-data file should be important for the deployment. According to the Ubuntu guide here, the meta-data file is kept empty.


Good eye! No indeed the installation doesn’t proceed with meta-data. I was focussed on having the plumbing working (fetching something via the proxy, and making it work).

I noticed afterwards that installation was via user-data and not meta-data, which I will pursue.

Disregard the meta-data fetch, but I will open an issue with the user-data using the mac from the proxy.

Source code ref where I got the hint to try with the mac:

Thanks for the hints and good job on Ubuntu 22.04!

1 Like

Good Morning All,

I’ve been trying to follow along this convo to setup Ubuntu 20.04 & 22.04 provisioning via Foreman but having troubles understanding what exactly needs to be done. So wondering if anyone here can either point me to an article with exact steps or provide me with the steps. Keep in mind Im very new to Foreman/Linux management and have only been doing this for 6 months. So trying my best to understand everything :smiley:

My Environment

  • Foreman Version: 3.3.0 - non ketello

  • OS Hosting Foreman: AlmaLinux 8.6

  • All foreman components on same server. Single server deployment currently.

  • This version has all the templates created earlier in this post with auto install in the name

    So far this post has been a bit confusing with steps for modifying tftp to steps for copying the ISO down and its contents to the correct folder structure. And its in all kinds of order lol. So just wondering if someone could write a step by step guide from step 1 to actually provisioning a Ubuntu machine. What templates do I need to use? What settings do I need to change in Foreman? etc.


Shawn OG


hi @sgoetz

I have picked up my work on docs for Ubuntu again: Procedures to provision hosts running Ubuntu 22.04. I will notify you once this has been reviewed and merged. cc @bastian-src

1 Like

Good news: we have merged documentation for Ubuntu Autoinstall:

Feedback is appreciated.

1 Like

Awesome docs @maximilian! I wrote a post trying to untangle everything to do with autoinstall on Ubuntu, I think it might help some other folks who stumble across this forum.

The biggest thing is how to modify the ISO to automatically boot (if desired) and some underyling components.

It’s essentially the doc I wish I found when starting to explore this topic, heh


Hi, Long time viewer of the forum, first time poster :slight_smile:

So i have to do a fresh build of some ubuntu 20.04 hosts and bumped into all these issues… - i even reinstalled my foreman host from scratch thinking i was having major dramas because of customising provisioning templates etc anyway…

For me the instructions largely work if you are in a plain PXE environment which we moved away from some time back due to the number of discrete subnets/networks we are running accross africa meant it wasn’t the most scalable for us - we use foreman_bootdisk with static IP addressing.

for us we had to hack the iPXE template that foreman_bootdisk chainloads to account for the new autoinstall params etc - thanks to this AskUbuntu link for guidance on getting the static config right for casper - networking - assign ip to ubuntu 20.04 during installation (packer/cloud-init context) - Ask Ubuntu

my iPXE template for Ubuntu 20.04 and assuming will work for 22.04 too is here - Preseed default iPXE - AUTOINSTALL · GitHub

it probably could do with a lot of cleanup/fixing (staticv6 is untested for example) but will help steer those using foreman_bootdisk

now the manuals say to copy the whole ISO contents to the pub directory - this might not be entirely required

from my server access logs the only files downloaded other than the iso itself (twice!)

i also saw these:


which were fine and also repeated hits on
which was giving a 404

i haven’t yet tried doing from a smart proxy

i now appear to be bumping into the eject cd rom issue in vmware again - will take a seperate look at that

Hey @anthonysomerset!

Thanks for your comment. The latest version of the PXELinux Autoinstall template does also support static IP deployment. Have a look here:

Do I understand you right that the bootdisk setup uses the PXELinux template still or does it take a different one?

The fact that your ISO is downloaded twice origins from a design issue of Ubuntu Autoinstall. You can append cloud-config-url=/dev/null. Have a look here:

I don’t quite understand the question in your post, could you elaborate it more? In case you want some help debugging your vmware issue: It sounds a bit like the typical error that occurs when the user-data template is not correct. Can you verify this?


The bootdisk plugin at least for the dynamic host specific iso chain loads iPXE and NOT PXELinux - I think for the generic host image it still uses the PXELinux but I have separate unrelated config issues to work through to get generic host images working in my environment

Will test with the cloud-config-url param because i was seeing weird issues when i had both cloud-init and user-data templates specified in the OS config - i didn’t have time to debug that other than to ensure i wasn’t specifying the cloud init template at all.

the cd eject issue was actually a byproduct of that issue - it actually doesn’t happen when only the proper autoinstall user-data is present as then the correct late commands are run which includes an eject command