Am Donnerstag, 4. April 2019, 15:20:00 CEST schrieb Tardif, Christian:
Yesterday, I tried to rebuilt my image as I had to add a few packages.... and it failed
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
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
Architecte principal infonuagique | Cloud computing senior Architect
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
From: Fabian Vogt <fvogt(a)suse.de>
Sent: Monday, March 18, 2019 2:14 PM
To: Tardif, Christian <christian.tardif(a)bell.ca>
Cc: opensuse-kubic(a)opensuse.org; Thorsten Kukuk <kukuk(a)suse.de>
Subject: Re: [opensuse-kubic] MicroOS custom image build
Am Montag, 18. März 2019, 17:40:04 CET schrieb Tardif, Christian:
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.
> 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:
> 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(a)bell.ca
> -----Original Message-----
> From: Fabian Vogt <fvogt(a)suse.de>
> Sent: Friday, March 15, 2019 3:53 PM
> To: Tardif, Christian <christian.tardif(a)bell.ca>
> Cc: opensuse-kubic(a)opensuse.org; Thorsten Kukuk <kukuk(a)suse.de>
> Subject: Re: [opensuse-kubic] MicroOS custom image build
> 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
> 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">
> kernelcmdline="plymouth.enable=0 console=ttyS0,115200 console=tty0
> <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"
> <volume name="usr/local"/>
> <volume name="var"
> > 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.
> > --
> > 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(a)bell.ca
> > -----Original Message-----
> > From: Fabian Vogt <fvogt(a)suse.de>
> > Sent: Thursday, March 14, 2019 4:35 PM
> > To: opensuse-kubic(a)opensuse.org
> > Cc: Thorsten Kukuk <kukuk(a)suse.de>de>; Tardif, Christian
> > <christian.tardif(a)bell.ca>
> > 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,
> > > > > 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(a)opensuse.org
> > To contact the owner, e-mail: opensuse-kubic+owner(a)opensuse.org
To unsubscribe, e-mail: opensuse-kubic+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kubic+owner(a)opensuse.org