Is this the place to ask about the boot_command? I am trying to use subiquity with packer. I can find no information about how to create the boot_command, but I have seen many examples, all extremely different, one worked with 20.04 but not with 21.10. There are lots of opinions about what the command should look like, but no explanation I can find how people create the boot command in the first place.
The autoinstaller does not start, so I am trying to figure out how the boot_command works and how to write one.
The PXE installer based on 20.04 update 4 seems to require more than 4GB of memory!
This means that you canāt PXE boot a physical machine if it doesnāt have at least 6 to 8 GB of memory, if we go by regular DIMM sizes.
Maybe Iām the only one who thinks this way, but I find it rather sad.
(in a VM I could only make the unattended install work with at least 4300 MB of memory)
Hello, I have a working PXE auto-installer however, trying to figure out how to copy the cloud image onto disk as part of auto-install. I see subiquity running ācp:///media/filesystemā to copy image to disk but wondering is there a way to overwrite that by specifying the cloud-image so the cloud image can be install to disk. The doc for curtin has option however, not working. Doing this would speed up the deployment and we will have exact same image on all systems.
Any help would be appreciated.
Hello, guys.
I am to install Ubuntu 20/04 with PXE boot and PXE auto-installer.
I use user-data:
runcmd:
to install all I need and to make files, etc.
But there is two problems:
First. It doesnāt work if command is multiline, line echo or cat
Second. If in command there is : then cloudinit after first reboot not starts. It crahes.
For example:
user-data:
runcmd:
- echo āansible ALL=(ALL) NOPASSWD: ALLā > /etc/sudoers.d/ansible
I got crashed installation.
If I change this to:
user-data:
runcmd:
- echo āansible ALL=(ALL) NOPASSWD**#** ALLā > /etc/sudoers.d/ansible
- sed -i -e ās/#/:/ā /etc/sudoers.d/ansible
it works;
So by that way I need to change all lines like that:
- echo ā{\n āinsecure-registriesā# [āharbor.my.locā, āk8s-prod-harbor.my.locā, āwerf-registry.kube-system.svc.cluster.localā, āregistry.vagrant-k8s-v2.localā]\n}ā > /etc/docker/daemon.json
- sed -i -e ās/#/:/ā /etc/docker/daemon.json
And it works.
BTW
Line
- echo āAcquire::http::proxy āhttp://10.10.0.17:3142/ā; \nAcquire::https::proxy āhttp://10.10.0.17:3142/ā;ā > /etc/apt/apt.conf.d/80proxy
works without changes.
Why in one line : (ASCII 58) stops the installer, in another lines symbol : will not crash installer and all is ok.
Is it ok?
Yes. Itās really so. You need at least 6GB of memory to install via PXE boot.
1 Like
I would suggest adding the full autoinstall scope and proper indentation like:
#cloud-config
autoinstall:
version: 1
reporting:
hook:
<snip>
and the indentation that comes with the full scope.
Problem
As like most people, Iāve cut & pasted the content of the example in my user-data and didnāt realize that all the content was one indentation too short.
(and the cloud-init software interpreter didnāt complain either, but thatās not for here.)
having a full example, or having an extra indentation could save people a lot of hours. It took me about 6 hours and the help of the Ubuntu community to figure it out
Solution documented here
Using autoinstall for ubuntu-20.04.4-live-server-amd64.iso here, and I cannot understand why it would consistently install a GNOME based desktop environment 
Some context, if anything here makes sense to explain the issue:
- Net booting environment
- apt-cacher-ng to save my bandwith and go faster on repeated installs
Iāve added a GRUB option in my netboot to boot on the exact same Ubuntu 20.04.4 Server without the autoinstall config: I can install manually, and no GNOME based desktop environment is ever installed (which is totally expected).
If I take the /var/log/autoinstall-user-data from that manual install and apply it, the autoinstall will proceed but it will - again - add a GNOME based desktop environment 
Hereās the full user-data file Iām using:
#cloud-config
autoinstall:
version: 1
network:
version: 2
ethernets:
id0:
match:
name: *
dhcp4: true
critical: true
wifis:
id1:
match:
name: *
optional: true
refresh-installer:
update: yes
identity:
hostname: whateverhostname
realname: whatever
username: whatever
password: "$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0"
timezone: Europe/Paris
locale: fr_FR.UTF-8
keyboard:
layout: "fr"
toggle: null
variant: ''
ssh:
install-server: true
allow-pw: false
authorized-keys:
- ssh-ed25519 MyPublicSSHKey my@email.com
proxy: http://192.168.1.50:3142/
updates: security
kernel:
package: linux-generic
drivers:
install: false
apt:
disable_components: []
geoip: true
preserve_sources_list: false
primary:
- arches:
- amd64
- i386
uri: http://fr.archive.ubuntu.com/ubuntu
- arches:
- default
uri: http://ports.ubuntu.com/ubuntu-ports
storage:
swap:
size: 0
config:
# the disk
- id: sda
type: disk
ptable: gpt
match:
size: largest
wipe: superblock-recursive
preserve: false
grub_device: true
# /dev/sda1
- id: sda1
type: partition
number: 1
size: 1GB
device: sda
flag: boot
# for a description why this shouldn't be there, but is needed anyways
# see https://discourse.ubuntu.com/t/please-test-autoinstalls-for-20-04/15250/340
grub_device: true
- id: sda1-format
type: format
fstype: fat32
volume: sda1
- id: sda1-mount
type: mount
path: /boot/efi
device: sda1-format
# /dev/sda2
- id: sda2
type: partition
number: 2
size: 10GB
device: sda
- id: sda2-format
type: format
fstype: ext4
volume: sda2
- id: sda2-mount
type: mount
path: /
device: sda2-format
# /dev/sda3
- id: sda3
type: partition
number: 3
size: 10GB
device: sda
flag: home
- id: sda3-format
type: format
fstype: ext4
volume: sda3
- id: sda3-mount
type: mount
path: /home
device: sda3-format
# /dev/sda4
- id: sda4
type: partition
number: 4
size: -1
device: sda
- id: sda4-format
type: format
fstype: ext4
volume: sda4
- id: sda4-mount
type: mount
path: /data
device: sda4-format
Did I miss something? That sounds so weird to meā¦ Any tip or pointer is welcome 
Hi,
the documentation page does not mention (or at least, I didnāt find it) where and how to report bugs in the autoinstallation. It just tells how to report bugs for the regular, interactive installer, which is not applicable here.
What I wanted to report:
The automated server install supports configuring a proxy in the autoinstallation file as a URL.
Nowadays, proxies should use TLS and have a https URL. Many programs complain about plain http, for good reason.
But typically, proxies are part of the LAN infrastructure and not publicy available. Therefore, they quite often have TLS certificates issued by some local CA, not an official one from a CA covered by the standard CA certificates.
It is possible to install certificates through the user-data file through cloud-init, but since is is usally run after installation, this probably comes too late or is not guaranteed. The web page should at least mention, how this is expected to be achieved.
The next guess would be to use early-commands or late-commands, but the form seems to be too early, the latter too late.
Install on USB works but Boot from USB doesnāt work on HP Microserver Gen8
Iāve tried everything I can think of but an Ubuntu 20.04 or 22.04 installation on a USB drive results in a system that perfectly installs, but on reboot never seems to boot from USB, it just falls back to PXE booting.
I donāt have this problem with Debian or Ubuntu 18.04 installations. That has worked fine for years.
Iāve even tried different USB enclosures for my SATA SSD. Iāve tried different SATA SSDs in different enclosures. The only thing that worked was a powered Dockingstation but thatās not a solution as it canāt fit in my Microserver.
Although it can be a quirk of the Microserver, (I donāt have other hardware to test on) since other operating systems work fine, Iām skeptical and I suspect an issue with the Autoinstaller.
For my own personal experience, the Autoinstaller is pain for zero gain. And that includes the scattered documentation, the undiscoverable way to configure storage (RAID and such).
I want to be mindful and respect all the work people have put into Autoinstaller, for some people it has probably been their full-time work. But Iām not happy about it at all, Iām sorry to say.
So, what about an automated install of 22.04 Desktop then?
Iām having issues setting up swap.
My current conf is:
storage:
swap:
filename: /swap.img
size: 3GB
layout:
name: direct
But no matter what values I put, remove filename and only have size, add maxsize, etc, no swapfile is created.
This is utilising ubuntu-22.04.1-live-server-amd64 via Packer.
The full config is:
#cloud-config
autoinstall:
version: 1
refresh-installer:
update: true
channel: stable
locale: en_GB
keyboard:
layout: gb
apt:
geoip: true
ssh:
install-server: true
allow-pw: true
disable_root: false
ssh_quiet_keygen: true
allow_public_ssh_keys: true
network:
version: 2
ethernets:
ens18:
dhcp4: true
package_update: true
package_upgrade: true
package_reboot_if_required: true
updates: all
packages:
- qemu-guest-agent
- sudo
- bash-completion
- cloud-init
- cloud-utils
- cloud-guest-utils
- git
- curl
- mlocate
- resolvconf
- htop
- net-tools
- dnsutils
- aptitude
- unzip
- tuned
- tuned-utils
- tuned-utils-systemtap
- tldr
- needrestart
- acl
- libsasl2-modules
storage:
swap:
filename: /swap.img
size: 3GB
layout:
name: direct
user-data:
timezone: geoip
users:
- name: packer
gecos: Packer User
no_user_group: true
groups: [adm, sudo]
lock-passwd: true
homedir: /tmp/packer
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
ssh_authorized_keys:
- ${ssh_key}Under storage, if you have a layout section then the swap (and grub) sections do not get used.
My notes from the last time I looked into this. The current source code still appears to behave the same way.
1 Like
Ah, thatās a bit bunch of pants.
Thanks for the reply, itās certainly stopped me blaming my config!
At least with no swap I can create a custom one.
Thanks again!!
Suggestion to improve the document
Location
- āIntroduction > Providing the autoinstall configā
Improvement suggestion
In the line:
In most scenarios the easiest way will be to provide user-data via the nocloud data source.
Replace the deadlink with https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html.
Thank you for catching that! Iāve updated the link now
I want to use layout and grub both on storage , so what should i do ?
Currently this seems to not be possible, however a fix for it is currently in progress. For updates on this I found the issue in Launchpad and an active pull request in GitHub
This probably isnāt the correct place to ask this question but for sure if someone can point me in a direction Iād be more than grateful.
Iām new to a lot of this stuff so please bare with me if I donāt use the correct terminology but basically, my question boils down to wondering if Iām correct in discovering (the hard way) that supported cloud-init modules != supported autoinstall modules ???
To be a bit more specific, I have a working PXE boot solution for booting both 20.04 and 22.04 live server ISOās that is booting and reading my user-data & meta-data files via http without any issues.
Iāve started to build my user-data file assuming (classic mistake) that all the modules specified at https://cloudinit.readthedocs.io/en/latest/reference/modules.html would work and be supported. What Iāve come to realize is that only the modules specified at https://ubuntu.com/server/docs/install/autoinstall-reference are actually supported because behind the scenes itās reading the data in the user-data file and creating an autoinstall.yml file for subiquity to use as itās answer file.
One example I ran into was wanting to use the cloud-init ansible module. This module isnāt listed as being supported in the autoinstall-reference so even if itās listed in the user-data file, it appears to me anyways that itās being ignored and not processed (ie. skipped) even though itās a valid cloud-init module.
The workaround we have come up with was to use a late-command to setup a firsrun.service to execute a bash script that launches ansible-pullā¦ it works but isnāt ideal. What Iām wondering is if someone who has a bit more experience with all this can confirm for me that supported cloud-init modules != supported autoinstall modules.
Also if anyone has any ideas or feedback on how we might be able to make better use of all of the cloud-init modules by installing off of the ISO media against bare metal Iād be all ears! Maybe Iāve missed something along the way. It seems that the problem that cloud-init was developed to solve might not work so great with using the ISO trying to install on bare metal systems.
Thoughts?
This bit is confusing. See the pseudo-yaml below for what I hope clarifies this situation.
#cloud-config
<cloud-init stuff affecting the install environment>
autoinstall:
<autoinstall stuff affecting the target system>
user-data:
<cloud-init stuff affecting the target system>
@dbungert did you just hear a loud bang? Because you just blew my mind! 
All joking asideā¦ this clears things up for sure. After all of the research, and hours of trial and error I donāt know why it didnāt occur to me to try this! Iāll echo some of the other comments in this thread in that information to tie all this together is a bit spread out but for sure it always amazes me how this community is always more than willing to help.
I canāt promise I wonāt have more questions but your psudo code has for sure opened my eyes. I canāt wait to get back to work and give this all a try.
My sincere thanks!