This appears more complicated than I first thought.... Basically, what I did (I may be all wrong): 1) Got a machine with kiwi installed 2) Downloaded every file from there: https://build.opensuse.org/package/show/devel:kubic:images/openSUSE-Tumblewe... and paced them in a directory called MicroOS 3) Changed the repo from the kiwi file to: <repository type="yast2" alias="Tumbleweed" imageinclude="true"> <source path="http://download.opensuse.org/tumbleweed/repo/oss"/> </repository> 4) Tried to run: kiwi-ng --type=oem --profile=hardware-x86_64 --debug system build --description=MicroOS --target-dir=/tmp/MicroOS (no luck, KiwiTypeNotFound: build type oem not found 5) Tried kiwi-ng --type=vmx --profile=hardware-x86_64 --debug system build --description=MicroOS --target-dir=/tmp/MicroOS (to figure out) It ran for a moment, then stopped with: + '[' -f /etc/sysconfig/network/dhcp ']' + echo 'warning: config file /etc/sysconfig/network/dhcp not found' + echo FONT=eurlatgr.psfu + echo '** Rehashing SSL Certificates...' + update-ca-certificates + for i in /usr/lib/rpm/gnupg/keys/gpg-pubkey*asc + rpm --import '/usr/lib/rpm/gnupg/keys/gpg-pubkey*asc' error: /usr/lib/rpm/gnupg/keys/gpg-pubkey*asc: import read failed(2). + true + '[' -x /usr/sbin/add-yast-repos ']' + add-yast-repos + zypper --non-interactive rm -u live-add-yast-repos + rpm -q kubernetes-kubelet + sed -i 's/.*solver.onlyRequires.*/solver.onlyRequires = true/g' /etc/zypp/zypp.conf + sed -i 's/.*rpm.install.excludedocs.*/rpm.install.excludedocs = yes/g' /etc/zypp/zypp.conf + sed -i 's/^multiversion =.*/multiversion =/g' /etc/zypp/zypp.conf + '[' true = true ']' + echo 'creating initial snapper config ...' + cp /etc/snapper/config-templates/default /etc/snapper/configs/root cp: cannot stat '/etc/snapper/config-templates/default': No such file or directory These are the last few line of the run.... don't exactly understand the issue.... Looks like I need some more explanations, unfortunately... Christian -----Original Message----- From: Fabian Vogt Sent: Wednesday, March 6, 2019 11:23 AM To: opensuse-kubic@opensuse.org Cc: Tardif, Christian Subject: Re: [opensuse-kubic] MicroOS custom image build Hi, Am Mittwoch, 6. März 2019, 17:08:33 CET schrieb Tardif, Christian:

Hi,

We're starting to look at MicroOS as the base OS for our Kubernetes stacks. And as we're now using RKE to deploy k8s, we're stuck with Docker right now.

Added to this, we have other things to customize in order to ease the OS deployment (mostly targeting, but not limited to bare metal deployment)

Two questions here: 1) Can I (I assume yes) leverage kiwi to build a raw image (as our metal deployer requires raw image)? If so, I haven't found how to do it in the available docs

Yes, that should work fine. Currently we're not building any raw images for x86_64, but for RaspberryPi and Pine64 it works. It might be enough to set "image='oem'" in the kiwi image type. You could also convert the qcow2 images to .raw if you don't need the automatic filesystem expansion. https://opensource.suse.com/kiwi/building/build_oem_disk.html https://build.opensuse.org/package/view_file/devel:kubic:images/openSUSE-Tum... Cheers, Fabian

2) Providing that everything is automated and standardized, using cloud-init NoCloud datasource is not an option (as it's unlikely we'll be having a connected unpartitioned disk to hold the cloud-init configuration), and I haven't been able to make the LocalDisk datasource (again, I most probably just haven't the docs required to make it work).

Thanks!

Christian

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Good insight.... I'll give it a try ! Thanks, Christian -----Original Message----- From: Thorsten Kukuk Sent: Wednesday, March 6, 2019 2:26 PM To: Tardif, Christian Cc: Fabian Vogt ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build On Wed, Mar 06, Tardif, Christian wrote:

This appears more complicated than I first thought.... Basically, what I did (I may be all wrong):

1) Got a machine with kiwi installed 2) Downloaded every file from there: https://build.opensuse.org/package/show/devel:kubic:images/openSUSE-Tu mbleweed-Kubic?rev=14 and paced them in a directory called MicroOS

There is a much easier, simpler and faster method to build this adjusted images: 1. Create a login for build.opensuse.org 2. Branch the package into your home project, adjust it, and let the build service build the image for you, everytime there are changes. So you will have always an up-to-date image. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

OK, got my account activated on OBS, then branched devel:kubic:images, created the repo (openSUSE-Tumbleweed, x86_64), then trying to figure out how to glue everything together so build actually works... P.S. I have a SUSE Partner Executive coming to our office on March 13 to help out. So I I can have something working by then, I may look a little more intelligent :-D -- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada -----Original Message----- From: Thorsten Kukuk Sent: Wednesday, March 6, 2019 2:26 PM To: Tardif, Christian Cc: Fabian Vogt ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build On Wed, Mar 06, Tardif, Christian wrote:

This appears more complicated than I first thought.... Basically, what I did (I may be all wrong):

1) Got a machine with kiwi installed 2) Downloaded every file from there: https://build.opensuse.org/package/show/devel:kubic:images/openSUSE-Tu mbleweed-Kubic?rev=14 and paced them in a directory called MicroOS

There is a much easier, simpler and faster method to build this adjusted images: 1. Create a login for build.opensuse.org 2. Branch the package into your home project, adjust it, and let the build service build the image for you, everytime there are changes. So you will have always an up-to-date image. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

I minimized the kiwi file to bare minimum: Openstack and hardware, x64_86, + docker package (adapted the _multibuild file accordingly) My project is home:tardich:Kubic, and the package name is: openSUSE-Tumbleweed-Kubic I now have two flavors: - MicroOS-docker-OpenStack-Cloud - MicroOS-docker-hardware-x86_64 On the right pane, I see that - openSUSE-Tumbleweed-Kubic - openSUSE-Tumbleweed-Kubic:MicroOS-docker-OpenStack-Cloud - openSUSE-Tumbleweed-Kubic:MicroOS-docker-hardware-x86_64 are in an "excluded" state I had to correct the kiwi file because of preferences version invalid (version was 15.0, where it seem to require three numbers, like 15.0.0). Still, I get no build at all, and I don't know what this means, nor where to look at to fix it... :-/ -- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca -----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 10:50 AM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build Hi, Am Donnerstag, 7. März 2019, 16:31:14 CET schrieb Tardif, Christian:

OK, got my account activated on OBS, then branched devel:kubic:images, created the repo (openSUSE-Tumbleweed, x86_64),

If you use the built-in branch functionality, the target project should be set up correctly for building already.

then trying to figure out how to glue everything together so build actually works...

It should be enough to replace the "container-runtime" namedCollection and package with a <package name="docker"/> - you could s/podman/docker/ as well, but if the name mismatch isn't bothering you, I recommend to just skip that as it keeps the diff small. Cheers, Fabian

P.S. I have a SUSE Partner Executive coming to our office on March 13 to help out. So I I can have something working by then, I may look a little more intelligent :-D -- Christian Tardif Cloud computing senior Architect

Network IaaS Bell Canada

-----Original Message----- From: Thorsten Kukuk Sent: Wednesday, March 6, 2019 2:26 PM To: Tardif, Christian Cc: Fabian Vogt ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

On Wed, Mar 06, Tardif, Christian wrote:

...

This appears more complicated than I first thought.... Basically, what I did (I may be all wrong):

1) Got a machine with kiwi installed 2) Downloaded every file from there: https://build.opensuse.org/package/show/devel:kubic:images/openSUSE- Tu mbleweed-Kubic?rev=14 and paced them in a directory called MicroOS

There is a much easier, simpler and faster method to build this adjusted images: 1. Create a login for build.opensuse.org 2. Branch the package into your home project, adjust it, and let the build service build the image for you, everytime there are changes. So you will have always an up-to-date image.

Thorsten

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Hi, Am Donnerstag, 7. März 2019, 18:11:12 CET schrieb Tardif, Christian:

I minimized the kiwi file to bare minimum: Openstack and hardware, x64_86, + docker package (adapted the _multibuild file accordingly)

I personally recommend to not do this and keep the diff as small as possible. Currently any changes in the source image description would cause a merge conflict which can only be fixed manually with osc on the command line.

My project is home:tardich:Kubic, and the package name is: openSUSE-Tumbleweed-Kubic

I now have two flavors: - MicroOS-docker-OpenStack-Cloud - MicroOS-docker-hardware-x86_64

On the right pane, I see that - openSUSE-Tumbleweed-Kubic - openSUSE-Tumbleweed-Kubic:MicroOS-docker-OpenStack-Cloud - openSUSE-Tumbleweed-Kubic:MicroOS-docker-hardware-x86_64

are in an "excluded" state

I had to correct the kiwi file because of preferences version invalid (version was 15.0, where it seem to require three numbers, like 15.0.0).

That seems weird - where did you get the error message?

Still, I get no build at all, and I don't know what this means, nor where to look at to fix it... :-/

That's because you created the "openSUSE_Tumbleweed" repository manually, which defaults to building RPM packages with .spec files. To change this, set "Type: kiwi" in the project config. If you branch the package, the project configuration is set up correctly out of the box. Your change to the kiwi file will not work as intended - the <!-- OBS-Profiles --> comment is not a list of all profiles to build separate images from, but rather a list of profiles enabled during any image build. The magic "@BUILD_FLAVOR@" string means that it builds every profile mentioned in _multibuild separately. I branched the package and applied some minimal changes to use docker instead, as an example: https://build.opensuse.org/package/show/home:favogt:fortardich/openSUSE-Tumb... Cheers, Fabian

-- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 10:50 AM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 7. März 2019, 16:31:14 CET schrieb Tardif, Christian:

...

OK, got my account activated on OBS, then branched devel:kubic:images, created the repo (openSUSE-Tumbleweed, x86_64),

If you use the built-in branch functionality, the target project should be set up correctly for building already.

...

then trying to figure out how to glue everything together so build actually works...

It should be enough to replace the "container-runtime" namedCollection and package with a <package name="docker"/> - you could s/podman/docker/ as well, but if the name mismatch isn't bothering you, I recommend to just skip that as it keeps the diff small.

Cheers, Fabian

...

P.S. I have a SUSE Partner Executive coming to our office on March 13 to help out. So I I can have something working by then, I may look a little more intelligent :-D -- Christian Tardif Cloud computing senior Architect

Network IaaS Bell Canada

-----Original Message----- From: Thorsten Kukuk Sent: Wednesday, March 6, 2019 2:26 PM To: Tardif, Christian Cc: Fabian Vogt ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

On Wed, Mar 06, Tardif, Christian wrote:

...

This appears more complicated than I first thought.... Basically, what I did (I may be all wrong):

1) Got a machine with kiwi installed 2) Downloaded every file from there: https://build.opensuse.org/package/show/devel:kubic:images/openSUSE- Tu mbleweed-Kubic?rev=14 and paced them in a directory called MicroOS

There is a much easier, simpler and faster method to build this adjusted images: 1. Create a login for build.opensuse.org 2. Branch the package into your home project, adjust it, and let the build service build the image for you, everytime there are changes. So you will have always an up-to-date image.

Thorsten

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Hi, Restarted from scratch, and branched from devel:kubic:images. Added my required stuff but, even before that, nothing builds. It seem that it does not find any repo from which to get packages. In the .kiwi file, the only relevant info regarding package repository is that: <repository type="rpm-md" > <source path='obsrepositories:/'/> </repository> Which seem to me to be like..... nothing. Can't seem to be able to find out any relevant info in order to fix this. Thanks, -- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada -----Original Message----- From: Tardif, Christian Sent: Thursday, March 7, 2019 4:03 PM To: Fabian Vogt Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: RE: [opensuse-kubic] MicroOS custom image build Good advice. I'll take it back tomorrow morning, redoing it from scratch. Anyway, that's not a big deal just to add my tiny stuff. At the actual point, I just need to figure out how to add the repo information (since my actual status is now "unresolvable (nothing provides kiwi-filesystem:btrfs, docker, xfsprogs, .......) for the build to actually start. -- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada -----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 1:19 PM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build Hi, Am Donnerstag, 7. März 2019, 18:11:12 CET schrieb Tardif, Christian:

I minimized the kiwi file to bare minimum: Openstack and hardware, x64_86, + docker package (adapted the _multibuild file accordingly)

I personally recommend to not do this and keep the diff as small as possible. Currently any changes in the source image description would cause a merge conflict which can only be fixed manually with osc on the command line.

My project is home:tardich:Kubic, and the package name is: openSUSE-Tumbleweed-Kubic

I now have two flavors: - MicroOS-docker-OpenStack-Cloud - MicroOS-docker-hardware-x86_64

On the right pane, I see that - openSUSE-Tumbleweed-Kubic - openSUSE-Tumbleweed-Kubic:MicroOS-docker-OpenStack-Cloud - openSUSE-Tumbleweed-Kubic:MicroOS-docker-hardware-x86_64

are in an "excluded" state

I had to correct the kiwi file because of preferences version invalid (version was 15.0, where it seem to require three numbers, like 15.0.0).

That seems weird - where did you get the error message?

Still, I get no build at all, and I don't know what this means, nor where to look at to fix it... :-/

That's because you created the "openSUSE_Tumbleweed" repository manually, which defaults to building RPM packages with .spec files. To change this, set "Type: kiwi" in the project config. If you branch the package, the project configuration is set up correctly out of the box. Your change to the kiwi file will not work as intended - the <!-- OBS-Profiles --> comment is not a list of all profiles to build separate images from, but rather a list of profiles enabled during any image build. The magic "@BUILD_FLAVOR@" string means that it builds every profile mentioned in _multibuild separately. I branched the package and applied some minimal changes to use docker instead, as an example: https://build.opensuse.org/package/show/home:favogt:fortardich/openSUSE-Tumb... Cheers, Fabian

-- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 10:50 AM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 7. März 2019, 16:31:14 CET schrieb Tardif, Christian:

...

OK, got my account activated on OBS, then branched devel:kubic:images, created the repo (openSUSE-Tumbleweed, x86_64),

If you use the built-in branch functionality, the target project should be set up correctly for building already.

...

then trying to figure out how to glue everything together so build actually works...

It should be enough to replace the "container-runtime" namedCollection and package with a <package name="docker"/> - you could s/podman/docker/ as well, but if the name mismatch isn't bothering you, I recommend to just skip that as it keeps the diff small.

Cheers, Fabian

...

P.S. I have a SUSE Partner Executive coming to our office on March 13 to help out. So I I can have something working by then, I may look a little more intelligent :-D -- Christian Tardif Cloud computing senior Architect

Network IaaS Bell Canada

-----Original Message----- From: Thorsten Kukuk Sent: Wednesday, March 6, 2019 2:26 PM To: Tardif, Christian Cc: Fabian Vogt ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

On Wed, Mar 06, Tardif, Christian wrote:

...

This appears more complicated than I first thought.... Basically, what I did (I may be all wrong):

1) Got a machine with kiwi installed 2) Downloaded every file from there: https://build.opensuse.org/package/show/devel:kubic:images/openSUS E- Tu mbleweed-Kubic?rev=14 and paced them in a directory called MicroOS

There is a much easier, simpler and faster method to build this adjusted images: 1. Create a login for build.opensuse.org 2. Branch the package into your home project, adjust it, and let the build service build the image for you, everytime there are changes. So you will have always an up-to-date image.

Thorsten

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Nope. Deleted my old project, recreated a new project (with a different project just to be sure), and branched from devel:kubic:images into it. Didn't change a line (so should be getting the exact same results as devel:kubic:images builds. But still getting the unresolvable packages issue. -- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada -----Original Message----- From: Fabian Vogt Sent: Tuesday, March 12, 2019 10:03 AM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build Hi, Am Dienstag, 12. März 2019, 14:54:00 CET schrieb Tardif, Christian:

Hi,

Restarted from scratch, and branched from devel:kubic:images. Added my required stuff but, even before that, nothing builds. It seem that it does not find any repo from which to get packages.

You branched into an already existing project, so it does not overwrite your old config. If you branch into a new project or delete the target project before branching into it, it will generate a working config.

In the .kiwi file, the only relevant info regarding package repository is that:

<repository type="rpm-md" > <source path='obsrepositories:/'/> </repository>

Which seem to me to be like..... nothing.

That means it uses the repos from the project configuration. Cheers, Fabian

Can't seem to be able to find out any relevant info in order to fix this.

Thanks,

-- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada

-----Original Message----- From: Tardif, Christian Sent: Thursday, March 7, 2019 4:03 PM To: Fabian Vogt Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: RE: [opensuse-kubic] MicroOS custom image build

Good advice. I'll take it back tomorrow morning, redoing it from scratch. Anyway, that's not a big deal just to add my tiny stuff. At the actual point, I just need to figure out how to add the repo information (since my actual status is now "unresolvable (nothing provides kiwi-filesystem:btrfs, docker, xfsprogs, .......) for the build to actually start.

-- Christian Tardif Cloud computing senior Architect

Network IaaS Bell Canada

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 1:19 PM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 7. März 2019, 18:11:12 CET schrieb Tardif, Christian:

...

I minimized the kiwi file to bare minimum: Openstack and hardware, x64_86, + docker package (adapted the _multibuild file accordingly)

I personally recommend to not do this and keep the diff as small as possible. Currently any changes in the source image description would cause a merge conflict which can only be fixed manually with osc on the command line.

...

My project is home:tardich:Kubic, and the package name is: openSUSE-Tumbleweed-Kubic

I now have two flavors: - MicroOS-docker-OpenStack-Cloud - MicroOS-docker-hardware-x86_64

On the right pane, I see that - openSUSE-Tumbleweed-Kubic - openSUSE-Tumbleweed-Kubic:MicroOS-docker-OpenStack-Cloud - openSUSE-Tumbleweed-Kubic:MicroOS-docker-hardware-x86_64

are in an "excluded" state

I had to correct the kiwi file because of preferences version invalid (version was 15.0, where it seem to require three numbers, like 15.0.0).

That seems weird - where did you get the error message?

...

Still, I get no build at all, and I don't know what this means, nor where to look at to fix it... :-/

That's because you created the "openSUSE_Tumbleweed" repository manually, which defaults to building RPM packages with .spec files. To change this, set "Type: kiwi" in the project config. If you branch the package, the project configuration is set up correctly out of the box.

Your change to the kiwi file will not work as intended - the <!-- OBS-Profiles --> comment is not a list of all profiles to build separate images from, but rather a list of profiles enabled during any image build. The magic "@BUILD_FLAVOR@" string means that it builds every profile mentioned in _multibuild separately.

I branched the package and applied some minimal changes to use docker instead, as an example: https://build.opensuse.org/package/show/home:favogt:fortardich/openSUS E-Tumbleweed-Kubic

Cheers, Fabian

...

-- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 10:50 AM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 7. März 2019, 16:31:14 CET schrieb Tardif, Christian:

...

OK, got my account activated on OBS, then branched devel:kubic:images, created the repo (openSUSE-Tumbleweed, x86_64),

If you use the built-in branch functionality, the target project should be set up correctly for building already.

...

then trying to figure out how to glue everything together so build actually works...

It should be enough to replace the "container-runtime" namedCollection and package with a <package name="docker"/> - you could s/podman/docker/ as well, but if the name mismatch isn't bothering you, I recommend to just skip that as it keeps the diff small.

Cheers, Fabian

...

P.S. I have a SUSE Partner Executive coming to our office on March 13 to help out. So I I can have something working by then, I may look a little more intelligent :-D -- Christian Tardif Cloud computing senior Architect

Network IaaS Bell Canada

-----Original Message----- From: Thorsten Kukuk Sent: Wednesday, March 6, 2019 2:26 PM To: Tardif, Christian Cc: Fabian Vogt ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

On Wed, Mar 06, Tardif, Christian wrote:

...

This appears more complicated than I first thought.... Basically, what I did (I may be all wrong):

1) Got a machine with kiwi installed 2) Downloaded every file from there: https://build.opensuse.org/package/show/devel:kubic:images/openS US E- Tu mbleweed-Kubic?rev=14 and paced them in a directory called MicroOS

There is a much easier, simpler and faster method to build this adjusted images: 1. Create a login for build.opensuse.org 2. Branch the package into your home project, adjust it, and let the build service build the image for you, everytime there are changes. So you will have always an up-to-date image.

Thorsten

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Hi, Am Dienstag, 12. März 2019, 16:10:25 CET schrieb Tardif, Christian:

Nope. Deleted my old project, recreated a new project (with a different project just to be sure), ^^^^^^^^^

The mistake is branching into an existing project - do not do that. Just skip the project creation and enter the name of a not existing project into the "Branch package" dialog. It'll set up the project for you, with the correct configuration. Cheers, Fabian

and branched from devel:kubic:images into it. Didn't change a line (so should be getting the exact same results as devel:kubic:images builds. But still getting the unresolvable packages issue.

-- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada

-----Original Message----- From: Fabian Vogt Sent: Tuesday, March 12, 2019 10:03 AM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Dienstag, 12. März 2019, 14:54:00 CET schrieb Tardif, Christian:

...

Hi,

Restarted from scratch, and branched from devel:kubic:images. Added my required stuff but, even before that, nothing builds. It seem that it does not find any repo from which to get packages.

You branched into an already existing project, so it does not overwrite your old config. If you branch into a new project or delete the target project before branching into it, it will generate a working config.

...

In the .kiwi file, the only relevant info regarding package repository is that:

<repository type="rpm-md" > <source path='obsrepositories:/'/> </repository>

Which seem to me to be like..... nothing.

That means it uses the repos from the project configuration.

Cheers, Fabian

...

Can't seem to be able to find out any relevant info in order to fix this.

Thanks,

-- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada

-----Original Message----- From: Tardif, Christian Sent: Thursday, March 7, 2019 4:03 PM To: Fabian Vogt Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: RE: [opensuse-kubic] MicroOS custom image build

Good advice. I'll take it back tomorrow morning, redoing it from scratch. Anyway, that's not a big deal just to add my tiny stuff. At the actual point, I just need to figure out how to add the repo information (since my actual status is now "unresolvable (nothing provides kiwi-filesystem:btrfs, docker, xfsprogs, .......) for the build to actually start.

-- Christian Tardif Cloud computing senior Architect

Network IaaS Bell Canada

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 1:19 PM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 7. März 2019, 18:11:12 CET schrieb Tardif, Christian:

...

I minimized the kiwi file to bare minimum: Openstack and hardware, x64_86, + docker package (adapted the _multibuild file accordingly)

I personally recommend to not do this and keep the diff as small as possible. Currently any changes in the source image description would cause a merge conflict which can only be fixed manually with osc on the command line.

...

My project is home:tardich:Kubic, and the package name is: openSUSE-Tumbleweed-Kubic

I now have two flavors: - MicroOS-docker-OpenStack-Cloud - MicroOS-docker-hardware-x86_64

On the right pane, I see that - openSUSE-Tumbleweed-Kubic - openSUSE-Tumbleweed-Kubic:MicroOS-docker-OpenStack-Cloud - openSUSE-Tumbleweed-Kubic:MicroOS-docker-hardware-x86_64

are in an "excluded" state

I had to correct the kiwi file because of preferences version invalid (version was 15.0, where it seem to require three numbers, like 15.0.0).

That seems weird - where did you get the error message?

...

Still, I get no build at all, and I don't know what this means, nor where to look at to fix it... :-/

That's because you created the "openSUSE_Tumbleweed" repository manually, which defaults to building RPM packages with .spec files. To change this, set "Type: kiwi" in the project config. If you branch the package, the project configuration is set up correctly out of the box.

Your change to the kiwi file will not work as intended - the <!-- OBS-Profiles --> comment is not a list of all profiles to build separate images from, but rather a list of profiles enabled during any image build. The magic "@BUILD_FLAVOR@" string means that it builds every profile mentioned in _multibuild separately.

I branched the package and applied some minimal changes to use docker instead, as an example: https://build.opensuse.org/package/show/home:favogt:fortardich/openSUS E-Tumbleweed-Kubic

Cheers, Fabian

...

-- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 10:50 AM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 7. März 2019, 16:31:14 CET schrieb Tardif, Christian:

...

OK, got my account activated on OBS, then branched devel:kubic:images, created the repo (openSUSE-Tumbleweed, x86_64),

If you use the built-in branch functionality, the target project should be set up correctly for building already.

...

then trying to figure out how to glue everything together so build actually works...

It should be enough to replace the "container-runtime" namedCollection and package with a <package name="docker"/> - you could s/podman/docker/ as well, but if the name mismatch isn't bothering you, I recommend to just skip that as it keeps the diff small.

Cheers, Fabian

...

P.S. I have a SUSE Partner Executive coming to our office on March 13 to help out. So I I can have something working by then, I may look a little more intelligent :-D -- Christian Tardif Cloud computing senior Architect

Network IaaS Bell Canada

-----Original Message----- From: Thorsten Kukuk Sent: Wednesday, March 6, 2019 2:26 PM To: Tardif, Christian Cc: Fabian Vogt ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

On Wed, Mar 06, Tardif, Christian wrote:

...

This appears more complicated than I first thought.... Basically, what I did (I may be all wrong):

1) Got a machine with kiwi installed 2) Downloaded every file from there: https://build.opensuse.org/package/show/devel:kubic:images/openS US E- Tu mbleweed-Kubic?rev=14 and paced them in a directory called MicroOS

There is a much easier, simpler and faster method to build this adjusted images: 1. Create a login for build.opensuse.org 2. Branch the package into your home project, adjust it, and let the build service build the image for you, everytime there are changes. So you will have always an up-to-date image.

Thorsten

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

One more question... Where is it where I can decide on the image size? Actually, for our deployments, we need to have a raw image. So the conversion comes from 400M or so up to 24G !!!! That's a important charge on the network for an OS deployment and, anyway, the disk should grow to take the remaining space, isn't it ? -- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca -----Original Message----- From: Tardif, Christian Sent: Wednesday, March 13, 2019 9:10 AM To: Fabian Vogt Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: RE: [opensuse-kubic] MicroOS custom image build Got it !!!! Right now, I see the project being built. I'll let him complete (actually, an exact copy of devel:kubic:images), then do the (minimal) modifications to suit my needs. Thanks, Richard and Fabian, for your help! Really appreciated ! -- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada -----Original Message----- From: Fabian Vogt Sent: Tuesday, March 12, 2019 4:24 PM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build Hi, Am Dienstag, 12. März 2019, 16:10:25 CET schrieb Tardif, Christian:

Nope. Deleted my old project, recreated a new project (with a different project just to be sure), ^^^^^^^^^

The mistake is branching into an existing project - do not do that. Just skip the project creation and enter the name of a not existing project into the "Branch package" dialog. It'll set up the project for you, with the correct configuration. Cheers, Fabian

and branched from devel:kubic:images into it. Didn't change a line (so should be getting the exact same results as devel:kubic:images builds. But still getting the unresolvable packages issue.

-- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada

-----Original Message----- From: Fabian Vogt Sent: Tuesday, March 12, 2019 10:03 AM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Dienstag, 12. März 2019, 14:54:00 CET schrieb Tardif, Christian:

...

Hi,

Restarted from scratch, and branched from devel:kubic:images. Added my required stuff but, even before that, nothing builds. It seem that it does not find any repo from which to get packages.

You branched into an already existing project, so it does not overwrite your old config. If you branch into a new project or delete the target project before branching into it, it will generate a working config.

...

In the .kiwi file, the only relevant info regarding package repository is that:

<repository type="rpm-md" > <source path='obsrepositories:/'/> </repository>

Which seem to me to be like..... nothing.

That means it uses the repos from the project configuration.

Cheers, Fabian

...

Can't seem to be able to find out any relevant info in order to fix this.

Thanks,

-- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada

-----Original Message----- From: Tardif, Christian Sent: Thursday, March 7, 2019 4:03 PM To: Fabian Vogt Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: RE: [opensuse-kubic] MicroOS custom image build

Good advice. I'll take it back tomorrow morning, redoing it from scratch. Anyway, that's not a big deal just to add my tiny stuff. At the actual point, I just need to figure out how to add the repo information (since my actual status is now "unresolvable (nothing provides kiwi-filesystem:btrfs, docker, xfsprogs, .......) for the build to actually start.

-- Christian Tardif Cloud computing senior Architect

Network IaaS Bell Canada

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 1:19 PM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 7. März 2019, 18:11:12 CET schrieb Tardif, Christian:

...

I minimized the kiwi file to bare minimum: Openstack and hardware, x64_86, + docker package (adapted the _multibuild file accordingly)

I personally recommend to not do this and keep the diff as small as possible. Currently any changes in the source image description would cause a merge conflict which can only be fixed manually with osc on the command line.

...

My project is home:tardich:Kubic, and the package name is: openSUSE-Tumbleweed-Kubic

I now have two flavors: - MicroOS-docker-OpenStack-Cloud - MicroOS-docker-hardware-x86_64

On the right pane, I see that - openSUSE-Tumbleweed-Kubic - openSUSE-Tumbleweed-Kubic:MicroOS-docker-OpenStack-Cloud - openSUSE-Tumbleweed-Kubic:MicroOS-docker-hardware-x86_64

are in an "excluded" state

I had to correct the kiwi file because of preferences version invalid (version was 15.0, where it seem to require three numbers, like 15.0.0).

That seems weird - where did you get the error message?

...

Still, I get no build at all, and I don't know what this means, nor where to look at to fix it... :-/

That's because you created the "openSUSE_Tumbleweed" repository manually, which defaults to building RPM packages with .spec files. To change this, set "Type: kiwi" in the project config. If you branch the package, the project configuration is set up correctly out of the box.

Your change to the kiwi file will not work as intended - the <!-- OBS-Profiles --> comment is not a list of all profiles to build separate images from, but rather a list of profiles enabled during any image build. The magic "@BUILD_FLAVOR@" string means that it builds every profile mentioned in _multibuild separately.

I branched the package and applied some minimal changes to use docker instead, as an example: https://build.opensuse.org/package/show/home:favogt:fortardich/openS US E-Tumbleweed-Kubic

Cheers, Fabian

...

-- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 7, 2019 10:50 AM To: Tardif, Christian Cc: Thorsten Kukuk ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 7. März 2019, 16:31:14 CET schrieb Tardif, Christian:

...

OK, got my account activated on OBS, then branched devel:kubic:images, created the repo (openSUSE-Tumbleweed, x86_64),

If you use the built-in branch functionality, the target project should be set up correctly for building already.

...

then trying to figure out how to glue everything together so build actually works...

It should be enough to replace the "container-runtime" namedCollection and package with a <package name="docker"/> - you could s/podman/docker/ as well, but if the name mismatch isn't bothering you, I recommend to just skip that as it keeps the diff small.

Cheers, Fabian

...

P.S. I have a SUSE Partner Executive coming to our office on March 13 to help out. So I I can have something working by then, I may look a little more intelligent :-D -- Christian Tardif Cloud computing senior Architect

Network IaaS Bell Canada

-----Original Message----- From: Thorsten Kukuk Sent: Wednesday, March 6, 2019 2:26 PM To: Tardif, Christian Cc: Fabian Vogt ; opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build

On Wed, Mar 06, Tardif, Christian wrote:

...

This appears more complicated than I first thought.... Basically, what I did (I may be all wrong):

1) Got a machine with kiwi installed 2) Downloaded every file from there: https://build.opensuse.org/package/show/devel:kubic:images/ope nS US E- Tu mbleweed-Kubic?rev=14 and paced them in a directory called MicroOS

There is a much easier, simpler and faster method to build this adjusted images: 1. Create a login for build.opensuse.org 2. Branch the package into your home project, adjust it, and let the build service build the image for you, everytime there are changes. So you will have always an up-to-date image.

Thorsten

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Hi, On Thu, Mar 14, Fabian Vogt wrote:

Hi,

Am Donnerstag, 14. März 2019, 19:35:42 CET schrieb Tardif, Christian:

...

One more question... Where is it where I can decide on the image size? Actually, for our deployments, we need to have a raw image. So the conversion comes from 400M or so up to 24G !!!! That's a important charge on the network for an OS deployment and, anyway, the disk should grow to take the remaining space, isn't it ?

Yes, if you use type="oem" the image grows automatically. Just write the decompressed .raw to a drive and it'll expand to fill the entire disk on the first boot. So there's no need to specify a size manually.

This is the kiwi special initrd, or? To my knowledge, this does not work with a read-only root filesystem. In this case, we normally use the growfs functionality of cloud-init. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Think I saw it working with baremetal, as far as I remember. But my question wasn't so much about the grow thing, but rather the image size itself. For example, my custom-built image (which is in compressed qcow2 format) is somewhere between 400M and 600M, which is good. But, in order to be able to use it in our Openstack implementation or in our metal deployer (MaaS, from Canonical) , it needs to be in raw format, which is easily converted with qemu-img. But then, the resulting image size is 24GB !!!! And guess what? 24GB takes a rather long amount of time to upload through the management network, which is typically a 1GB link. So this is why I was asking where could I tell OBS to create a smaller image (in fact, the smallest possible) where it would then grow to disk size once installed. If I'm not mistaking, MicroOS does not resize / (third partition). Instead, it creates a 4th partition with the remaining size and assign it to something like /var/lib/docker (or something like that). -- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca -----Original Message----- From: Fabian Vogt Sent: Thursday, March 14, 2019 4:35 PM To: opensuse-kubic@opensuse.org Cc: Thorsten Kukuk ; Tardif, Christian Subject: Re: [opensuse-kubic] MicroOS custom image build Hi, Am Donnerstag, 14. März 2019, 21:27:49 CET schrieb Thorsten Kukuk:

Hi,

On Thu, Mar 14, Fabian Vogt wrote:

...

Hi,

Am Donnerstag, 14. März 2019, 19:35:42 CET schrieb Tardif, Christian:

...

One more question... Where is it where I can decide on the image size? Actually, for our deployments, we need to have a raw image. So the conversion comes from 400M or so up to 24G !!!! That's a important charge on the network for an OS deployment and, anyway, the disk should grow to take the remaining space, isn't it ?

Yes, if you use type="oem" the image grows automatically. Just write the decompressed .raw to a drive and it'll expand to fill the entire disk on the first boot. So there's no need to specify a size manually.

This is the kiwi special initrd, or? To my knowledge, this does not work with a read-only root filesystem. In this case, we normally use the growfs functionality of cloud-init.

Nope, it's the normal initrd with just a kiwi-specific module enabled. All it has to do is growing the btrfs partition mounted at /, so I don't see any problems there. I never tried it on real hardware yet though. Cheers, Fabian

Thorsten

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Hi, Do not make much progress today... :-/ Changed, on one of the profiles, vmx to oem, and nothing else... then, I'm facing a build issue: "Boot description missing for 'oem' type" But when I'm looking at any other profiles that uses oem, I don't see much differences. Well, I see some, but everytime I'm trying to modify something, I'm getting an error saying: "bad link: conflict n file openSUSE-Tumbleweed-Kubic.kiwi" That is, even if the only change is: changing the image size from 24 to 16 (can't just remove the line, anyway....) Project link: https://build.opensuse.org/package/show/home:tardich:branches:devel:kubic:im... -- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca -----Original Message----- From: Fabian Vogt Sent: Friday, March 15, 2019 3:53 PM To: Tardif, Christian Cc: opensuse-kubic@opensuse.org; Thorsten Kukuk Subject: Re: [opensuse-kubic] MicroOS custom image build Hi, Am Freitag, 15. März 2019, 18:11:10 CET schrieb Tardif, Christian:

Think I saw it working with baremetal, as far as I remember.

But my question wasn't so much about the grow thing, but rather the image size itself. For example, my custom-built image (which is in compressed qcow2 format) is somewhere between 400M and 600M, which is good. But, in order to be able to use it in our Openstack implementation or in our metal deployer (MaaS, from Canonical) , it needs to be in raw format, which is easily converted with qemu-img. But then, the resulting image size is 24GB !!!! And guess what? 24GB takes a rather long amount of time to upload through the management network, which is typically a 1GB link.

So this is why I was asking where could I tell OBS to create a smaller image (in fact, the smallest possible) where it would then grow to disk size once installed.

That you get .qcow2 images means you're not using the "oem" type, so you also don't have autoresizing enabled. That's what "oem" is for, it produces auto-resizing .raw files. The size is set by <size unit="G" unpartitioned="10">24</size> (the unpartitioned attribute here is not necessary anymore, I'll fix that) Just use "oem" and remove the <size/> element entirely and you get a raw image with its size based on its contents. Try this (untested): <preferences profiles="OpenStack-Cloud-x86_64"> <version>15.0</version> <packagemanager>zypper</packagemanager> <bootsplash-theme>openSUSE</bootsplash-theme> <bootloader-theme>openSUSE</bootloader-theme> <rpm-excludedocs>true</rpm-excludedocs> <type image="oem" initrd_system="dracut" filesystem="btrfs" format="qcow2" bootloader="grub2" bootloader_console="gfxterm" firmware="uefi" kernelcmdline="plymouth.enable=0 console=ttyS0,115200 console=tty0 net.ifnames=0 swapaccount=1" bootpartition="false" bootkernel="custom" devicepersistency="by-label" btrfs_root_is_snapshot="true" btrfs_root_is_readonly_snapshot="true" btrfs_quota_groups="false" > <systemdisk> <volume name="home"/> <volume name="root"/> <volume name="tmp"/> <volume name="opt"/> <volume name="srv"/> <volume name="boot/grub2/i386-pc"/> <volume name="boot/grub2/x86_64-efi" mountpoint="boot/grub2/x86_64-efi"/> <volume name="usr/local"/> <volume name="var" copy_on_write="false"/> </systemdisk> <oemconfig> <oem-swap>false</oem-swap> <oem-skip-verify>true</oem-skip-verify> </oemconfig> </type> </preferences>

If I'm not mistaking, MicroOS does not resize / (third partition). Instead, it creates a 4th partition with the remaining size and assign it to something like /var/lib/docker (or something like that).

That's no longer true as docker is not used in those images anymore. An installation using the DVD results in /var on a separate partition with quotas disabled, but kiwi does not support that. So instead, / is a single btrfs partiton and quotas are turned off entirely. Cheers, Fabian

-- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 14, 2019 4:35 PM To: opensuse-kubic@opensuse.org Cc: Thorsten Kukuk ; Tardif, Christian Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 14. März 2019, 21:27:49 CET schrieb Thorsten Kukuk:

...

Hi,

On Thu, Mar 14, Fabian Vogt wrote:

...

Hi,

Am Donnerstag, 14. März 2019, 19:35:42 CET schrieb Tardif, Christian:

...

One more question... Where is it where I can decide on the image size? Actually, for our deployments, we need to have a raw image. So the conversion comes from 400M or so up to 24G !!!! That's a important charge on the network for an OS deployment and, anyway, the disk should grow to take the remaining space, isn't it ?

Yes, if you use type="oem" the image grows automatically. Just write the decompressed .raw to a drive and it'll expand to fill the entire disk on the first boot. So there's no need to specify a size manually.

This is the kiwi special initrd, or? To my knowledge, this does not work with a read-only root filesystem. In this case, we normally use the growfs functionality of cloud-init.

Nope, it's the normal initrd with just a kiwi-specific module enabled. All it has to do is growing the btrfs partition mounted at /, so I don't see any problems there. I never tried it on real hardware yet though.

Cheers, Fabian

...

Thorsten

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

YEAH !!!!!!!! :-) Now, I got everything working !!! Image got built, is really small, the filesystem got resized on reboot, and I no longer need any type of conversion, as the resulting image (raw.xz) is able to be handled automatically by our metal deployer !!! Wonderful support by all of you! Thanks ! -- Christian Tardif Cloud computing senior Architect Network IaaS Bell Canada -----Original Message----- From: Fabian Vogt Sent: Monday, March 18, 2019 2:14 PM To: Tardif, Christian Cc: opensuse-kubic@opensuse.org; Thorsten Kukuk Subject: Re: [opensuse-kubic] MicroOS custom image build Hi, Am Montag, 18. März 2019, 17:40:04 CET schrieb Tardif, Christian:

Hi,

Do not make much progress today... :-/

Changed, on one of the profiles, vmx to oem, and nothing else... then, I'm facing a build issue: "Boot description missing for 'oem' type"

You need the 'initrd_system="dracut"' attribute in the type as well.

But when I'm looking at any other profiles that uses oem, I don't see much differences. Well, I see some, but everytime I'm trying to modify something, I'm getting an error saying:

"bad link: conflict n file openSUSE-Tumbleweed-Kubic.kiwi"

That's because a fix got checked into the package you branched from and now there's a merge conflict. The way to fix that properly is to use "osc pull" in a local checkout. You could also sever the link between your project and the source project by deleting the _link file you can see after clicking on "show unmerged sources". In that case you would need to add any fixes made in the source package after you branched manually, if you want them. Cheers, Fabian

That is, even if the only change is: changing the image size from 24 to 16 (can't just remove the line, anyway....)

Project link: https://build.opensuse.org/package/show/home:tardich:branches:devel:ku bic:images/openSUSE-Tumbleweed-Kubic -- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Friday, March 15, 2019 3:53 PM To: Tardif, Christian Cc: opensuse-kubic@opensuse.org; Thorsten Kukuk Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Freitag, 15. März 2019, 18:11:10 CET schrieb Tardif, Christian:

...

Think I saw it working with baremetal, as far as I remember.

But my question wasn't so much about the grow thing, but rather the image size itself. For example, my custom-built image (which is in compressed qcow2 format) is somewhere between 400M and 600M, which is good. But, in order to be able to use it in our Openstack implementation or in our metal deployer (MaaS, from Canonical) , it needs to be in raw format, which is easily converted with qemu-img. But then, the resulting image size is 24GB !!!! And guess what? 24GB takes a rather long amount of time to upload through the management network, which is typically a 1GB link.

So this is why I was asking where could I tell OBS to create a smaller image (in fact, the smallest possible) where it would then grow to disk size once installed.

That you get .qcow2 images means you're not using the "oem" type, so you also don't have autoresizing enabled. That's what "oem" is for, it produces auto-resizing .raw files.

The size is set by <size unit="G" unpartitioned="10">24</size>

(the unpartitioned attribute here is not necessary anymore, I'll fix that)

Just use "oem" and remove the <size/> element entirely and you get a raw image with its size based on its contents.

Try this (untested):

<preferences profiles="OpenStack-Cloud-x86_64"> <version>15.0</version> <packagemanager>zypper</packagemanager> <bootsplash-theme>openSUSE</bootsplash-theme> <bootloader-theme>openSUSE</bootloader-theme> <rpm-excludedocs>true</rpm-excludedocs> <type image="oem" initrd_system="dracut" filesystem="btrfs" format="qcow2" bootloader="grub2" bootloader_console="gfxterm" firmware="uefi" kernelcmdline="plymouth.enable=0 console=ttyS0,115200 console=tty0 net.ifnames=0 swapaccount=1" bootpartition="false" bootkernel="custom" devicepersistency="by-label" btrfs_root_is_snapshot="true" btrfs_root_is_readonly_snapshot="true" btrfs_quota_groups="false" > <systemdisk> <volume name="home"/> <volume name="root"/> <volume name="tmp"/> <volume name="opt"/> <volume name="srv"/> <volume name="boot/grub2/i386-pc"/> <volume name="boot/grub2/x86_64-efi" mountpoint="boot/grub2/x86_64-efi"/> <volume name="usr/local"/> <volume name="var" copy_on_write="false"/> </systemdisk> <oemconfig> <oem-swap>false</oem-swap> <oem-skip-verify>true</oem-skip-verify> </oemconfig> </type> </preferences>

...

If I'm not mistaking, MicroOS does not resize / (third partition). Instead, it creates a 4th partition with the remaining size and assign it to something like /var/lib/docker (or something like that).

That's no longer true as docker is not used in those images anymore. An installation using the DVD results in /var on a separate partition with quotas disabled, but kiwi does not support that. So instead, / is a single btrfs partiton and quotas are turned off entirely.

Cheers, Fabian

...

-- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 14, 2019 4:35 PM To: opensuse-kubic@opensuse.org Cc: Thorsten Kukuk ; Tardif, Christian Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 14. März 2019, 21:27:49 CET schrieb Thorsten Kukuk:

...

Hi,

On Thu, Mar 14, Fabian Vogt wrote:

...

Hi,

Am Donnerstag, 14. März 2019, 19:35:42 CET schrieb Tardif, Christian:

...

One more question... Where is it where I can decide on the image size? Actually, for our deployments, we need to have a raw image. So the conversion comes from 400M or so up to 24G !!!! That's a important charge on the network for an OS deployment and, anyway, the disk should grow to take the remaining space, isn't it ?

Yes, if you use type="oem" the image grows automatically. Just write the decompressed .raw to a drive and it'll expand to fill the entire disk on the first boot. So there's no need to specify a size manually.

This is the kiwi special initrd, or? To my knowledge, this does not work with a read-only root filesystem. In this case, we normally use the growfs functionality of cloud-init.

Nope, it's the normal initrd with just a kiwi-specific module enabled. All it has to do is growing the btrfs partition mounted at /, so I don't see any problems there. I never tried it on real hardware yet though.

Cheers, Fabian

...

Thorsten

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Hi, Am Donnerstag, 4. April 2019, 15:20:00 CEST schrieb Tardif, Christian:

Hey Fabian,

Yesterday, I tried to rebuilt my image as I had to add a few packages.... and it failed because:

Files could not be expanded: conflict in file openSUSE-Tumbleweed-Kubic.kiwi

I see that you changed it (on the source) on April 2nd.

There are currently some major structural changes ongoing, so this is somewhat expected. There's some unavoidable fallout during this process. The best option currently is to branch from openSUSE:Factory/openSUSE-Tumbleweed-Kubic instead of devel:kubic:images. That way you won't see any intermediate broken state anymore. Unfortunately that's not trivial as the Web UI doesn't allow that, what you can do is use "osc bco --nodevelproject openSUSE:Factory openSUSE-Tumbleweed-Kubic" or change your existing branch project by clicking on "(show unmerged sources)" and editing the _link file to use 'project="openSUSE:Factory"'. Apparently there's a weird issue with OBS though that makes the image unresolvable - a workaround for that is to remove all "" elements from the .kiwi file, those aren't strictly necessary anyway. I asked an OBS expert to have a look at that, so hopefully that'll be fixed soon.

How can I make sure I can merge back your changes prior doing my ow changes?

That happens automatically. When there are conflicts, it's necessary to use the osc tool to resolve it, using "osc pull" and "osc resolved". You can read more about osc on https://openbuildservice.org/help/manuals/obs-beginners-guide Cheers, Fabian

Thanks,

-- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Monday, March 18, 2019 2:14 PM To: Tardif, Christian Cc: opensuse-kubic@opensuse.org; Thorsten Kukuk Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Montag, 18. März 2019, 17:40:04 CET schrieb Tardif, Christian:

...

Hi,

Do not make much progress today... :-/

Changed, on one of the profiles, vmx to oem, and nothing else... then, I'm facing a build issue: "Boot description missing for 'oem' type"

You need the 'initrd_system="dracut"' attribute in the type as well.

...

But when I'm looking at any other profiles that uses oem, I don't see much differences. Well, I see some, but everytime I'm trying to modify something, I'm getting an error saying:

"bad link: conflict n file openSUSE-Tumbleweed-Kubic.kiwi"

That's because a fix got checked into the package you branched from and now there's a merge conflict. The way to fix that properly is to use "osc pull" in a local checkout. You could also sever the link between your project and the source project by deleting the _link file you can see after clicking on "show unmerged sources". In that case you would need to add any fixes made in the source package after you branched manually, if you want them.

Cheers, Fabian

...

That is, even if the only change is: changing the image size from 24 to 16 (can't just remove the line, anyway....)

Project link: https://build.opensuse.org/package/show/home:tardich:branches:devel:ku bic:images/openSUSE-Tumbleweed-Kubic -- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Friday, March 15, 2019 3:53 PM To: Tardif, Christian Cc: opensuse-kubic@opensuse.org; Thorsten Kukuk Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Freitag, 15. März 2019, 18:11:10 CET schrieb Tardif, Christian:

...

Think I saw it working with baremetal, as far as I remember.

But my question wasn't so much about the grow thing, but rather the image size itself. For example, my custom-built image (which is in compressed qcow2 format) is somewhere between 400M and 600M, which is good. But, in order to be able to use it in our Openstack implementation or in our metal deployer (MaaS, from Canonical) , it needs to be in raw format, which is easily converted with qemu-img. But then, the resulting image size is 24GB !!!! And guess what? 24GB takes a rather long amount of time to upload through the management network, which is typically a 1GB link.

So this is why I was asking where could I tell OBS to create a smaller image (in fact, the smallest possible) where it would then grow to disk size once installed.

That you get .qcow2 images means you're not using the "oem" type, so you also don't have autoresizing enabled. That's what "oem" is for, it produces auto-resizing .raw files.

The size is set by <size unit="G" unpartitioned="10">24</size>

(the unpartitioned attribute here is not necessary anymore, I'll fix that)

Just use "oem" and remove the <size/> element entirely and you get a raw image with its size based on its contents.

Try this (untested):

<preferences profiles="OpenStack-Cloud-x86_64"> <version>15.0</version> <packagemanager>zypper</packagemanager> <bootsplash-theme>openSUSE</bootsplash-theme> <bootloader-theme>openSUSE</bootloader-theme> <rpm-excludedocs>true</rpm-excludedocs> <type image="oem" initrd_system="dracut" filesystem="btrfs" format="qcow2" bootloader="grub2" bootloader_console="gfxterm" firmware="uefi" kernelcmdline="plymouth.enable=0 console=ttyS0,115200 console=tty0 net.ifnames=0 swapaccount=1" bootpartition="false" bootkernel="custom" devicepersistency="by-label" btrfs_root_is_snapshot="true" btrfs_root_is_readonly_snapshot="true" btrfs_quota_groups="false" > <systemdisk> <volume name="home"/> <volume name="root"/> <volume name="tmp"/> <volume name="opt"/> <volume name="srv"/> <volume name="boot/grub2/i386-pc"/> <volume name="boot/grub2/x86_64-efi" mountpoint="boot/grub2/x86_64-efi"/> <volume name="usr/local"/> <volume name="var" copy_on_write="false"/> </systemdisk> <oemconfig> <oem-swap>false</oem-swap> <oem-skip-verify>true</oem-skip-verify> </oemconfig> </type> </preferences>

...

If I'm not mistaking, MicroOS does not resize / (third partition). Instead, it creates a 4th partition with the remaining size and assign it to something like /var/lib/docker (or something like that).

That's no longer true as docker is not used in those images anymore. An installation using the DVD results in /var on a separate partition with quotas disabled, but kiwi does not support that. So instead, / is a single btrfs partiton and quotas are turned off entirely.

Cheers, Fabian

...

-- Christian Tardif Architecte principal infonuagique | Cloud computing senior Architect

Network IaaS Bell Canada 671, de la Gauchetière Ouest, suite 527 Montréal (Québec) H3B 2M8 T : 514.391.6635, C : 514.237.6332, F : 514.391.6690 Email: christian.tardif@bell.ca

-----Original Message----- From: Fabian Vogt Sent: Thursday, March 14, 2019 4:35 PM To: opensuse-kubic@opensuse.org Cc: Thorsten Kukuk ; Tardif, Christian Subject: Re: [opensuse-kubic] MicroOS custom image build

Hi,

Am Donnerstag, 14. März 2019, 21:27:49 CET schrieb Thorsten Kukuk:

...

Hi,

On Thu, Mar 14, Fabian Vogt wrote:

...

Hi,

Am Donnerstag, 14. März 2019, 19:35:42 CET schrieb Tardif, Christian:

...

One more question... Where is it where I can decide on the image size? Actually, for our deployments, we need to have a raw image. So the conversion comes from 400M or so up to 24G !!!! That's a important charge on the network for an OS deployment and, anyway, the disk should grow to take the remaining space, isn't it ?

Yes, if you use type="oem" the image grows automatically. Just write the decompressed .raw to a drive and it'll expand to fill the entire disk on the first boot. So there's no need to specify a size manually.

This is the kiwi special initrd, or? To my knowledge, this does not work with a read-only root filesystem. In this case, we normally use the growfs functionality of cloud-init.

Nope, it's the normal initrd with just a kiwi-specific module enabled. All it has to do is growing the btrfs partition mounted at /, so I don't see any problems there. I never tried it on real hardware yet though.

Cheers, Fabian

...

Thorsten

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Regarding the cloud-init thing... I started testing with one image available in the openSUSE repo: openSUSE-Tumbleweed-Kubic.x86_64-15.0-MicroOS-cri-o-hardware-x86_64-Build4.5.qcow2 (yes, think this is the one). In fact, I had to convert it to raw format because of our metal deployer. Then I set the cloud-init files under /cloud-init-config (the meta-data and user-data files, with really simple stuff to start with). Deployed the OS, the rebooted it. I saw it creating a partition for the remaining space, allocating it to /var/lib/docker and...... nothing else. I didn't saw any evidence of a cloud-init run. I haven't figured out what's going wrong.... Christian -----Original Message----- From: Richard Brown Sent: Wednesday, March 6, 2019 11:27 AM To: opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build Hi Christian, On Wed, 6 Mar 2019 at 17:08, Tardif, Christian wrote:

Hi,

We're starting to look at MicroOS as the base OS for our Kubernetes stacks. And as we're now using RKE to deploy k8s, we're stuck with Docker right now.

So cool, thanks for letting us know!

Added to this, we have other things to customize in order to ease the OS deployment (mostly targeting, but not limited to bare metal deployment)

Two questions here: 1) Can I (I assume yes) leverage kiwi to build a raw image (as our metal deployer requires raw image)? If so, I haven't found how to do it in the available docs

I think Fabian has already answered this question

2) Providing that everything is automated and standardized, using cloud-init NoCloud datasource is not an option (as it's unlikely we'll be having a connected unpartitioned disk to hold the cloud-init configuration), and I haven't been able to make the LocalDisk datasource (again, I most probably just haven't the docs required to make it work).

Um, I'm afraid I'm having a hard time under standing the question here. What is the problems you've found with LocalDisk datasource? Does it work if you put the required files in a /cloud-init-config folder? Regards, Richard

Thanks!

Christian -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org

Apart from image customization (like installing docker, creating a default user, removing unwanted services, that kind of things), the cloud-init still need to happen at some point (the ssh keys is different, depending on who is using the image; the network has to be configured (these are the two things that comes in my mind, right on the spot) Regarding ignition switch...... GO !!!! :-D Used it with CoreOS, until we decided to drop CoreOS as it will eventually (sooner than later) only be available under OpenShift use case, which won't necessarily be our use case, or the only one). And this is where MicroOS came into play. I'll try your suggestion regarding ds-identify thing. It may help. Thanks, Christian -----Original Message----- From: Thorsten Kukuk Sent: Wednesday, March 6, 2019 2:22 PM To: Tardif, Christian Cc: opensuse-kubic@opensuse.org Subject: Re: [opensuse-kubic] MicroOS custom image build Hello, On Wed, Mar 06, Tardif, Christian wrote:

Two questions here: 2) Providing that everything is automated and standardized, using cloud-init NoCloud datasource is not an option (as it's unlikely we'll be having a connected unpartitioned disk to hold the cloud-init configuration), and I haven't been able to make the LocalDisk datasource (again, I most probably just haven't the docs required to make it work).

Beside answers I also have some questions about this. Why do you need to configure the image with cloud-init, if the configuration file is already part of the image itself? Wouldn't it be easier to directly configure the image correct at build time? Or what is your usecase here? And what do you want to configure with it? I'm asking because we will replace cloud-init for Non-Cloud environments with ignition short to midterm. cloud-init is big and slows down the boot process dramatically and has for our usecase quite some design issues. About your problem: since MicroOS is small and boots fast (it only has very few services), we see from time to time race conditions with some applications. Especially ds-identify/cloud-init-generator from cloud-init have a problem here and don't detect datasources reliable. Beside that "LocalDisk" is not yet integrated (and most likely will not if we switch to ignition). When you create the image, you could create a file /etc/cloud/ds-identify.cfg with the content: "policy: enabled". Most likely ds=nocloud or ds=localdisk could also help. But I haven't tested that. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org