Please test autoinstalls for 20.04!

This is how the netplan config looks after the Installation. Static IP configuration is ignored. If you’ve another idea please let me know, I’ll test it.

$ cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s3:
      dhcp4: true
  version: 2

Here is correct grub config for your case
set gfxpayload=keep
linux /casper/vmlinuz “ds=nocloud-net;s=http://10.0.2.2:8028/” quiet autoinstall —
initrd /casper/initrd
boot

1 Like

I got the same issue while booted in MBR mode.
With UEFI it does work fine.

Quotes required here ds=nocloud;s=/
Have to be “ds=nocloud;s=/”

Ighor:

I have a similar case to blackline-silverfiel. I am trying to to hit a server to bring down user_data and metadata so I can do automated installs from an existing web server.

I’ve got two questions based on the documentation and the answers I’ve seen here so far.

First: every example of hitting a server I have seen does not drop down into directories. Is this supposed to work?:

linux /casper/vmlinuz “ds=nocloud-net;s=http://[some ip or name]/path/to/somewhere/” quiet autoinstall —

Secondly: does this work from isolinux or does this work from UEFI only? I don’t have a UEFI machine for testing right now so I have been trying to do everything with legacy boots, either by going into Expert mode and changing to command line there. Either way I don’t see any affect and the installer goes into a normal server install.

Thanks…
–dcl

I missed a thought here. I tried making a custom ISO with isolinux’s txt.cfg changed and that does not work either.

I’m trying to get “autoinstall” into an existing PXELINUX setup.
Copied vmlinuz and initrd from a mounted ISO onto the bootserver and setup a VM that NEEDS a CD-ROM image to be mounted (or lots of errors regarding /dev/sr0 will show and any type of booting will fail).

So I got this in file pxelinux.cfg/ubuntu.menu:

LABEL Ubuntu 20.04 Focal (amd64, autoinstall)
  KERNEL ubuntu/focal/amd64/vmlinuz
  APPEND initrd=ubuntu/focal/amd64/initrd autoinstall ds=nocloud-net;s=http://192.168.1.1:81/kickseeds/ubuntu/cloud-init/

Both user-data and empty meta-data are in place.

So what’s the catch to do a PXEboot like server setup as we were used to with preseed-based installations?

To clairfy I am booting using the 20.04 live installer and trying to do auto installs onto the bare metal machines. I also just did a test setting up virutalbox to use EFI and had the exact same outcome. I can’t get the install to do anything but go into init-local and I don’t see any indication it is even trying to activate the network interface and pull down any files.

My working example, still needs an ISO repack, does not work with vfat
https://gist.github.com/s3rj1k/55b10cd20f31542046018fcce32f103e

1 Like

The lines I pasted only for grub command line.
So it should work with any legacy or UEFI bios.

I can’t get them to run in either context using 20.04 live install. Is there anything else besides changing the grub command line that has to be done to get nocloud-net to work?

Checkout my gist, should work on UEFI and none-UEFI
https://gist.github.com/s3rj1k/55b10cd20f31542046018fcce32f103e

1 Like

This is possibly off-topic, but I’m happy to see that a regular / “legacy” PXEboot server setup with preseed is still possible. :innocent:
I added another entry in file pxelinux.cfg/ubuntu.menu :

LABEL Ubuntu 20.04 Focal (amd64, preseed)
  KERNEL ubuntu/focal/amd64/vmlinuz
  APPEND url=http://192.168.1.1:81/kickseeds/ubuntu/preseed/preseed.cfg auto=true priority=critical vga=normal initrd=ubuntu/focal/amd64/initrd.gz noquiet -- ipv6.disable=0

Using the initrd.gz from legacy-images/netboot (the kernel linux is identical to vmlinuz from the ISO) from here:

http://nl.archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/ubuntu-installer/amd64/

Thanks, I am keeping that in my back pocket. A fallback position is definitely building custom isos for my different type of installs.

I still would like to know if nocloud-net can be used with the 20.04 live install on bare metal hardware. I don’t really see anyone posting an example of that working. It seems to work using kvm and running a python http server on the same hardware.

I’ve gotten it working (mostly) on VirtualBox for macOS. Here’s what I have so far on getting a VM up with autoinstall/user-data using a second, vfat-formatted “CIDATA” disk to hold the config, but it’s still a draft, so I expect more to change.

I’ve got more data. I finally found the log file for the cloud boots and every time I see this:

DataSourceNoCloud.py[DEBUG]: Seed from http://x.x.x.x/some/path/to/user_data not supported by DataSourceNoCloud [seed=None] [dsmode=net]
(I have pointed to user_data explicitly in grub)

The log on the server’s end shows that the file is being hit.

I’ve tried several test user_data files, the latest is the plain “hello world” type of file that I’ve gotten to use with external vfat drives in the past:

#cloud-config
autoinstall:
  version: 1
  identity:
hostname: ubuntu-server
password: "$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0"
username: ubuntu

It might not look right on here, but the indents are ok in the file. I can also wget this file just fine from the console.

Anyone know what is going on? Is there a section missing here for the case of nocloud-net or something that needs to be adjusted in apache?

Just wondering: what if you use user-data instead?

Oh jesssh… you are right. I was using underbar… I’ve just went totally blind to it. I am changing the files on the server now.

Also it absolutely does not work pointing to an individual file in grub. After finally getting it through my head to grep for Cloud-Init as the agent I could see it was tring to fetch file “user_datameta-data”.

Sorry… like I said I am a real newb here.

I’ve set up a netboot automated install, and it worked just fine.

I did discover a problem when trying to set up a non-automated install (just setting the default proxy, with everything still interactive).

Non-working config:

#cloud-config
autoinstall:
  version: 1
  interactive-sections: *
  proxy: "http://my-proxy-server:3142/"

With this config, the proxy still defaults to empty.

If I replace interactive-sections: * with an explicit list of all sections, then my proxy server appears as the default, as expected. So I can work around the problem (but it’s still a problem)

Working config:

#cloud-config
autoinstall:
  version: 1
  interactive-sections:
   - locale
   - refresh-installer
   - keyboard
   - network
   - proxy
   - apt
   - storage
   - identity
   - ssh
   - snaps
  proxy: "http://my-proxy-server:3142/"

I’ve been trying to get this to work for a couple of days on and off.
And I’ve run into numerous problems. The fact that the config is a Python yaml file is a nightmare! Managing tabs and spaces gives no end of headaches.

Debugging your config is difficult at best. You have to wait for it to crash and boy does it ever crash. There is no way to verify your config beforehand. To see that it is even syntacticly right. So you have to boot up an install and try it out.
And instead of a good error message telling you that your config syntax is wrong or your network config is borked you get a mystical systemd-cat python3 -m curtin blah blah exited with error code 3. Then you have to login on an alternate console to check the log file that the documentation does not mention. Wade through tons of unimportant bits to find why this time your config was ignored/caused a crash. The fact that config errors cause crashes puts people off.

The documentation is just plain wrong in some cases (network config is not used after reboot) , Incomplete and just gives pointers to other documentation that is difficult in and of itself (cloud-init, netplan). There is no debugging/troubleshooting section at all in the documentation. That says a lot.

Running late-commands causes your defined users not to be created at all. Even though the rest of your config is used.

Having to pass kernel command line parameters to start autoinstall in clunky, because you have to provide kernel and initrd separately. So you have to extract them from the iso.

2 Likes