Support for openSUSE 15.4 image

Features
,
1

Hi,

I am trying to put together a custom image of openSUSE 15.4 via packer utilizing the packer-maas repo. I have gotten so far as to compile and upload the image to maas, but in the deployment phase the machine keeps failing to deploy.

From my perspective, something appears to be happening in the boot process and maas times out after 30 minutes of trying to deploy the image. I’m trying to debug the issue, but am yet to get any helpful debug information to try to resolve the issue.

What options do I have for getting logs and adding more debug information?

I’ve installed the following snap:
installed: 3.4.0~rc1-14283-g.89901d5cb (29077) 139MB -

On the maas region+rack controller I’m looking through logs in:
/var/snap/maas/common/log

I don’t appear to be able to SSH into the machine while it’s deploying.

2

Hi @westhusing and welcome to the community!

Unfortunately, as far as I know, openSUSE is not currently supported by packer-maas. I’ll change this to a feature request

1 Like
3

Hi @westhusing,

Actually I stand corrected, from 3.4 it should be possible to craft an OpenSUSE image using packer maas. Contributions are more than welcome :slight_smile:

4

hey @westhusing

I am currently doing the same task with a similar issue, if not the same.
I am just going to hijack your thread in the hopes that we both get increased visibility and at one point will be able to write a solid answer on how simply pack and autoprovision openSUSE images with packer for MAAS.

I am currently building different custom images with HashiCorps packer 1.9.2.
Building on Ubuntu 22.04 works so far.

I used the SLES15 template from the official git repositories.
https://github.com/canonical/packer-maas
Instead of the SLES15 ISO I decided to use OpenSuse Leap 15.4.

This requires some editing of the autoyast file in the http subfolder (see readme). The one provided comes with modules and reference for SLES and some closed sources. After editing this, I was able to create a successful build. Import into maas via API works, too.

When deploying after the first reboot, I am left with this

image
image1348×117 25.2 KB

I tried to create that folder and copy contents from similar folders in to the one mentioned in the screenshot (there is also a boot-tgz in a suse15 folder somewhere else (generic) that I placed on this location, too) but so far it made no difference.

I would be generally grateful if some can point me in a general direction how to resolve this.

My next approach will be to use an existing openSUSE installation, have an autoyast created from that, then rebuild, then try another deploy. I can’t say what causes the issue, yet.

I will also try to build a centOs8-stream custom stock images and see if I can get that to deploy.

I am on maasserver MAAS : 3.4.0~rc1, snap version.

I read somewhere that a snap permission issue existed in the past, that blocked access to the folder structure for some applications relevant for this process. But I am not sure if this is still relevant here.

Also, I will have to look further into the topic of tags. I guess this to be boot kernel related (please correct me if I am wrong) and thought the right kernel parameters via tags could help.

Edit:

The command I used to import my openSUSE custom image

maas admin boot-resources create name='custom/suse15' title='suse15' architecture='amd64/generic' filetype='tgz' content@=sles15.tar.gz

I just saw in another thread a more complex boot resource command.
I will give it a try tomorrow. Maybe I am “just” missing some parameters.

https://discourse.maas.io/t/proposed-improvements-for-custom-image-handling-in-maas/7297

Edit2:

Same error with a custom centos8-stream image.
The custom image was built with stock configuration from the template.
So the solution must be within MAAS or the import command.
I used the same command as mentioned above.

Edit3:

Fri, 11 Aug. 2023 10:20:43 HTTP Request - /images/custom/amd64/ga-20.04/cenost8stream/no-such-image/boot-kernel
Fri, 11 Aug. 2023 10:20:43 Marking node failed - Missing boot image custom/amd64/ga-20.04/cenost8stream.
Fri, 11 Aug. 2023 10:20:43 HTTP Request - pxelinux.cfg/01-00-50-56-8b-25-d9
Fri, 11 Aug. 2023 10:20:43 Performing PXE boot
5

Quick note before it gets forgotten:

maas admin boot-resources create name='custom/suse15' title='suse15' architecture='amd64/generic' filetype='tgz' content@=sles15.tar.gz

As suspected you need to change the name attribute in the command:

name='custom/suse15

to

name='suse/suse15

This way MAAS will assign it to the right directory and the correct “boot kernels” (?) will be assigned. This way I was able to get past this initial error.

I am facing now new issues. Will updated once I know more.

Another thing I encountered when packing with Qemu and openSUSE: It wouldn’t recognize my disks. As far as I remember, a problem with the disk UUID. I changed the following to /added in the packer file:

disk_interface=virtio-scsi

https://developer.hashicorp.com/packer/plugins/builders/qemu#disk_interface

This way I was able to finalize the packing of one image.

6

Hey @provisard
Were you still facing issues with centos8-stream?
We’ve recently started rolling out new internal testing of MAAS images, we were able to build centos8-stream from packer-MAAS repo (commit 44209f087f7340cd6cbe1c626509ef9d14d5fa23 was the latest at the time) and deploy it on MAAS 3.4.0~rc1-14296-g.8519ba431

You also mentioned being able to get a lot further through the SUSE deploy that @westhusing was originally asking about, but encountered a new issue? Which issue(s) were encountered, and could you create a quick bug report on packer MAAS?

7

Hey lloydwaltersj,

I was at the time trying to autoprovision vms with vmware.
Mostly the disk setup provided by QEMU got me in trouble when deploying.
Hda sda nvme that thing. I remember getting a custom centOS-8-stream to run.
With suse / opensuse I ran into an error possibly opensuse and vm ware related and the ones mentioned before.

Maybe down the line someone will find this helpful:

disk.EnableUUID = “TRUE”

another opensuse vmware issue, that occured when deploying with maas.
https://www.mail-archive.com/linux-doc@vger.kernel.org/msg34134.html

We moved away from MAAS for now.