Yet if I don’t repeat the grub_device key both in the type: disk and the type: partition (the one that is afterwards mounted to /bios/efi) then subiquity’s needs_bootloader_partition function will inaccurately return True, which in turn fails the install.
As soon as the second grub_device: true is added on the partition, autoinstall just proceeds, which is totally what dipo003’s GitHub links are showing right from the code
Here’s the relevant excerpt from my user-data file:
storage:
swap:
size: 0
config:
- id: sda
type: disk
ptable: gpt
match:
size: largest
wipe: superblock-recursive
preserve: false
grub_device: true
- id: sda1
type: partition
number: 1
size: 1GB
device: sda
flag: boot
# that shouldn't be here, but is needed for autoinstall to go through!
grub_device: true
- id: sda1-format
type: format
fstype: fat32
volume: sda1
- id: sda1-mount
type: mount
path: /boot/efi
device: sda1-format
Sigh, that’s not right, or at least that’s not the full story. When booting with UEFI, you can indicate an ESP that should be installed to by setting grub_device on the partition (see this code: curthooks.py « commands « curtin - curtin - [no description]). I guess you’re right that curtin is more lenient than subiquity here.
I also don’t think you need to set grub_device on the disk at all for UEFI boot but it’s also not harmful…
Sounds like we should suggest an update to curtin documentation, shouldn’t we?
Won’t have the machine with me today, but later this week, and if that helps, I can try putting the grub_device key on the partition only and not the disk, to confirm that.
Yes, probably. I actually wanted to clean this whole area up and make the config saner (for example, it really ought to be possible to install a system that will boot both legacy and UEFI) but it doesn’t look like I’m going to get around to that any time soon…
The commands in runcmd are run as root. These are run before the installation even begins. You might want to use late-commands (which also run as root). The users configured do not get created until the first boot after installation.
Has anything been added to support user interaction in early-commands scripts?
Also, has any work been done on this? I’m trying to supply most but not all the values for a static network configuration using either user-data or the autoinstall.yaml file that’s been updated by my early-commands script. In either case, my supplied default values are ignored and I need to manually enter them if the network section is interactive. That seems to go against what is stated in the documentation:
Would stop on the network screen and allow the user to change the defaults. If a value is provided for an interactive section it is used as the default.
i use 22.04 LTS and if i add those lines to my autoconfig it fails
after i login to shell i can see my shell script at /cdrom/nocloud/ubuntu_init.sh
i can execute shell script with success manuel.
my need is to execute my post install shell script from a local dir or remote server …
I posted this on a similar thread that I found helpful, I hope to come across as helpful and not spammy (happy to remove if considered spam):
I spent a lot of time trying to untangle this topic and I think I was able to summarize all the moving parts in a single blog post . Thanks for everyone’s comments / feedback here, I hope this helps the next person who stumbles across this.
menuentry "Autoinstall" {
set gfxpayload=keep
linux /casper/vmlinuz autoinstall ds=nocloud-net\;s=http://10.99.70.14/ ---
initrd /casper/initrd
}
During the loading of the operating system, attempts to download files are not recorded on the web server where the user-data and meta-data files are located.
After downloading live-os, I checked the availability of the files with the command “wget http://10.99.70.14/user-data” and the file downloads fine.
But if I use a server iso image, the files are downloaded and the automatic installation starts
Why is the installer not trying to download files?
Has anyone figured out how to resolve this issue? I think I’m seeing the same thing.
Also, has anyone figured out a way to repackage the Ubuntu installer ISO to contain the cloud config user-data and meta-data all on one ISO?
I can successfully get the auto-install to work with my user-data and meta-data files as long as they are on a separate ‘cidata’ ISO loaded in a 2nd CD/DVD drive. I would like to get a way to boot from a single ISO and have it auto-install.
One bump that has hit me a couple of times with providing menu entries to grub is that grub’s “shell” actually interpret’s the semicolon ‘;’ as the end of line and therfore truncates the trailing s=http://10.99.70...../ content. I’ve found in my case when editing the grub config live in the menu I have had to single-quote the 'ds=nocloud-net;s=http://YOUR_IP/'
To validate whether you’ve hit this symptom and grub shell truncated your commandline params you can run: cat /proc/cmdline and hopefully you’ll see the full ds=nocloud-net;s=http://YOUR_IP/ instead of just ds=nocloud-net.
As cloud-init is ultimately the service trying to download your user-data files, one can also check whether your autoinstall user-data was presented to your booted machine: sudo cloud-init query userdata
If the response is empty, cloud-init never saw your kernel cmdline config.
I am having some fustration with the setup of some servers with ubuntu 20, the server do not have dhcp so I need a static IP.
So I have create a iso with a basic cloudinit config with a early-command which run a script that scan all the network cards macaddress and find the relavent cloudinit file and copies it to /autoinstall.yaml but the network config fail.
I have tried using the early command to configure the netplan but subquity breaks it all (not fun).
Could you provide additional information, such as logs, the configuration being used, and the error you are seeing? If possible, a reproducer could also help figuring out what is going on here.