Wait are you saying that you have config that worked with subiquity 20.04.3 (the version on release day) that doesn’t work with 20.05.1? That shouldn’t be the case, I tried to be backwards compatible, although it’s always possible I messed that up.
I will try with:
locale: en_US.UTF-8
keyboard:
layout: es,us
variant: winkeys
Then, in a postscript try to add other lang (but now I not known howto do this… Ubuntu is newer for me)
On other thing,
When I try to add a network configuration, like this (I using refresh-installer to yes):
network:
ethernets:
eth0:
dhcp4: true
dhcp6: true
eth1:
dhcp4: true
dhcp6: true
eth2:
dhcp4: true
dhcp6: true
eth3:
dhcp4: true
dhcp6: true
version: 2
Then the installer not end (virtualbox). In one reboot, shown login.
I try to use this settings: https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls/ConfigReference#network
I’ve been following around for the last few days attempting to repackage an ISO I can use on disk or usb as needed without the need to attempt to mount multiple volumes via IDRAC etc.
I worked through most of the networking issues that took 3 days to puzzle out. The
refresh-installer:
update: yes
Section seems to not resolve the double network: key requirement and also intruduces the snap issue seen above. Stating that it cannot resolve the URL for it. My main concern is how I verify the networking is giving me an actual connection? On the crash, whether the netplan apply succeeded or not I cannot ping out. I can check the netplan section of /etc/ only to find that it was not recognizing my matches.
network:
network:
version: 2
ethernets:
id0:
match:
name: e*
dhcp4: true
while my /etc/netplan/
# This is the network config written by 'subiquity'
network:
version: 2
ethernets:
id0:
match:
name: e*
dhcp4: true
Subiquity does not look like it is actually reading the match criteria. The ethernet ID is ens3 which matches on our 18.04 servers. I am not sure, where I am missing it. I am attempting to manually apply and I’ll report back.
Well if the attempt to refresh the snap fails it’s not very surprising that you don’t get the fixes that are contained in the new version of the snap?
I’m not sure what is going on when you attempt to update the snap though, I’ve not seen this error. I’m aware this is tricky in an autoinstall environment but can you get the .crash file that’s being generated out somehow?
Well, in this code path it’s not subiquity that reads the match criteria but rather netplan (or well, netplan translates the match criteria to the format networkd uses). IOW this config should still get you a working network.
Sorry no ideas. Logs please?
From what you say, which makes sense its all down to not getting a network due to netplan not reading my match correctly. With no network, no refresh can really happen.
The issue currently with getting the logs is attempting to extract the data from a VM with no networking, clipboard, or shared filesystems. Once I figure out networking I am sure I can extract the logs from another run. Unfortunately, I am limited to a single VM at a time right now so any logs from current runs are discarded with the VM.
In the testing, I see:
The locale not change (always set C.UTF-8), using (the docs say en_US.UTF-8 as default):
locale en
locale en_US
locale en_US.UTF-8
And a working keyboard is:
keyboard:
layout: es,us
variant: winkeys
Other parameters can not set (XKBMODEL):
Not set (but configure always pc105):
XKBMODEL=pc105
In a postconfig I need to do this.
I need to find where logs are written, it will take a while to find them 
Yes, this makes sense.
Yes, this is no kind of fun. I’m not sure what sort of access you have to your VMs, if you can switch to tty2 you’ll find a shell there. Or you can try putting some interactive-sections in your autoinstall and then using the ‘switch to shell’ option.
If the install completes, they will be in /var/log/installer in the installed system.
I ran the build again and found the issue in the networking netplan file (which was a tab misplacement instead of 2 spaces, absolutely infuriating) and now it functions as expected until it hits some of my extra curtin commands. Which lead me to believe that my section for Identity is not actually creating the initial user per the documentation:
identity:
realname: UBUNTU_REMOVE_ME
username: ubuntu
password: ******************
hostname: changeme
The curtin command:
- curtin in-target --target=/target -- passwd -q -x -1 ubuntu
- curtin in-target --target=/target -- passwd -q -e ubuntu
Basically to make sure that we don’t have a superuser floating around on our servers unaccounted for.
The error is:
Which is true when I check /etc/passwd.
A number of users and yourself noted that the documented identity section doesn’t work, but give no further details. How in the future are we do provision the initial user outside of using the ubuntu-server that is chosen when Identity: is ignored or using root, which has its own security implications. I did modify @ zarej gist to accomplish most of my own goals but am attempting to create a true auto-install were as he still has interactive for identity, bypassing this issue, and networking, which has since been solved by many.
I was able to obtain the logs for this one and post them if you would like them, though I think they will just show that the identity section does not function as it seems is intended per your previous posts?
I am now attempting to get a working user-data user setup and expire out the ubuntu-server and installer user as both look to not be needed after the run.
Wow, I cannot spell. Nor can I edit my post to fix the spelling?
Argh, how annoying.
The user isn’t created until first boot (when cloud-init does it).
The ubuntu-server and installer accounts only exist in the live session, never at all in the target system.
1 Like
I’m trying to get a network boot & autoinstallation functioning to start converting my environment from the old d-i preseed mechanism.
After installing grub, curtin(?) runs efibootmgr and sets the first entry in the BootOrder to BootCurrent. Since I’m netbooting this causes the system to netboot again and go through another autoinstallataion cycle. This repeats endlessly until manual intervention.
I have not been able to location documentation on how to change this behavior.
I can provide more logs but the relevant bits from curtin-install.log are below. (‘0015’ is the network that was booted from and ‘0005’ is the newly installed SSD.)
- echo after grub-install efiboot settings
after grub-install efiboot settings - efibootmgr -v
BootCurrent: 0015
Timeout: 0 seconds
BootOrder: 0005,000F,0015,000C,000D,0009,0000,0001,0002,0003,0004,000A,000B,0006,0007,0008
[…]
Running command [‘unshare’, ‘–fork’, ‘–pid’, ‘–’, ‘chroot’, ‘/target’, ‘efibootmgr’, ‘-o’, ‘0015,0005,000F,000C,000D,0009,0000,0001,0002,0003,0004,000A,000B’] with allowed return codes [0] (capture=False)
BootCurrent: 0015
Timeout: 0 seconds
BootOrder: 0015,0005,000F,000C,000D,0009,0000,0001,0002,0003,0004,000A,000B
1 Like
I had this issue also. I found an undocumented curtin option to disable reordering uefi boot order. Subiquity happens to pass the storage config to curtin fairly untouched, so I added this to my autoinstall user-data
storage:
grub:
reorder_uefi: False
I put my full process up at
https://askubuntu.com/questions/1235723/automated-20-04-server-installation-using-pxe-and-live-server-image
3 Likes
Hi,
One strange error finded. If I write:
#cloud-config
autoinstall:
...
The cloud-init is executed
If I write:
# Configuration file for cloud-init
autoinstall:
...
The cloud-init is not executed.
???
That worked.
Thanks!
Perfect, I removed the curtin commands and confirmed this is correct. However, the password on the user is incorrect. I set a simple password for the user of root1! to test but this is not the password for the user. I am going to rerun my build to see if I missed anything that could cause this. If it fails again I’ll log into safe mode and check the password by decrypting it if I can, though I think I can just verify the hashes match.
I am also almost certain this needs to go into the documentation of the auto installer for future reference, as I am sure many will attempt something like this.
I believe this is specifically because the python yaml interpreter uses the #cloud-config as a key for cloud-init to interpret the file as a cloud-init yaml file. You can place any number of comments after that line, but that line needs to come first according to my tests.
How are you creating the crypted password you put into user-data? I can certainly log into the systems I am autoinstalling for testing purposes. I did run into some quoting issues at times.
Yes probably.
Yes, the details of user-data are documented here: https://cloudinit.readthedocs.io/en/latest/topics/format.html
Hi,
Using https://releases.ubuntu.com/20.04/ubuntu-20.04-live-server-amd64.iso and try to print logs to serial com, the installer stucks (https://www.virtualbox.org/wiki/Serial_redirect)
Howto deal with this?
Regards