Prepare image with Hashicorp Packer

Hello everyone

I am trying to setup a local KVM cluster and want to experiment with the following tool stack:

  1. Packer to prepare an image
  2. Terraform provision image
  3. Maybe Ansible/Pulumi for configmanagement

Since it looks like the industry is moving towards immutable infrastructure my pick as an OS was Opensuse Micro (also because I use Tumbleweed as my Desktop).

Unfortunately I am having trouble getting a working Packer setup running which triggers Autoyast for an unattended installation.

source "qemu" "demo" {
  iso_url           = ""
*#  iso_checksum      = "file:"
*iso_checksum      = "none"
output_directory  = "output_micro_demo"
shutdown_command  = "echo 'packer' | sudo -S shutdown -P now"
disk_size         = "5000M"
format            = "qcow2" *# default
*accelerator       = "kvm"
ssh_username      = "root"
ssh_password      = "s0m3password"
ssh_timeout       = "20m"
vm_name           = "demo"
net_device        = "virtio-net"
disk_interface    = "virtio"
cd_label          = "cidata"
cd_files          = "./autoinst.xml"]
  boot_wait         = "2s"
boot_command      = "c", "autoyast=device://cidata/autoinst.xml", "<enter>"]
*#  boot_command = "<esc><enter><wait>"]
**#  headless = true

build {
  sources = "source.qemu.demo"]

The ideas was to “mount” the autoinst.xml on an addition cd-rom drive hoping it will be picked up. Unfortunately this didnt work. Actually I think that I am missing something on how to properly boot the headless-installer in general.

I did find someones repo with some Leap 15.3 Packer templates, but the boot command does not work for me at all (probably the device-config).

It would be great if Suse could provide a sample Github repo or docu on how to get things started.
My hope is that someone here has a working Packer sample which I could apply…

I use MicroOS (Tumbleweed for the moment) with vagrant/libvirt, I use ignition for some initial configuration eg to set root password, ssh keys etc to get to a bootable cluster/system to deploy workloads.

Can you watch the console output when it boots to see where it may be hanging?

Well, when I just start the installer with <down><enter> it still presents me the ui and then fails with some block-device-error.

When I follow the Leap-15.3 template from the linked repo

"linux ",
"biosdevname=0 ",
"net.ifnames=0 ",
"netdevice=eth0 ",
"netsetup=dhcp ",
"lang=en_US ",
"textmode=1 ",

It might be hard to debug this here because there are 3 different stacks at play (packer, autoyast, micro) and at none I am proficient. Hence I hoped to find some known-to-be-working starting sample.

I wonder if you work backwards as in boot MicroOS in a vm and see what it’s doing/not doing?

My workflow is;

Prepare an ignition iso;

  • root user
  • root password
  • ssh keys
  • ssh config
  • cluster seed token
  • k8s network config

Create ignition iso

Prepare Vagrantfile

Vagrant up

Cluster running…

I do have an open issue ( with the switch to NetworkManager and setting static ip’s as this worked fine with Wicked. But my clusters come up fine with a dhcp address

Something went wrong when editing the previous post and now I cannot edit any more.

I meant that when I use the custom boot command, then grub fails completely complaining about the network device

“c” puts you in grub2 command line. Which certainly cannot do anytihng with command “autoyast=device://cidata/autoinst.xml”.

Boot in normal interactive mode and find out the proper keyboard input sequence to do what you want.

Hint - editing grub2 menu entry in blind mode is not the most pleasant experience. You may find it easier to actually go into CLI and simply enter necessary commands instead (basically copying content of menu entry into boot_command).

Ok thanks. I thought that I can force the installer into autoyast mode and disable any user-interaction (forcing the installer to list anything that is wrong). Upon reading a bit more about autoyast it seems it is “just” an automated user.

Of course you can. What you cannot is throwing a random input at some program and expecting it to do anything useful.

boot_command      = "<down>", "e", "<down>", "<down>", "<down>", "<down>", "<down>", "<left>", " autoyast=device://cidata/autoinst.xml", "<f10>"]

Upon reading a bit more about autoyast it seems it is “just” an automated user.

That I do not understand at all.

Yeah you are right. I totally underestimated the complexity of this. Since I just wanted to start with a default installation (no custom partitioning…everything as default as possible) I expected that I just need to pass a simple autoyast-file (auto-confirm) and tell Packer to start the iso with the autoyast config.

I guess divide-and-conquer is at order: I should first try to get autoyast working with a manual setup vm and once that works, add the next layer (packer) and so on.

Sorry for the confusion. I mixed the boot_command from Packer (simulation user input ) with autoyast.

Some Admin: feel free to delete this post. It was poorly created by me and probably doesn’t provide useful information for others