Hello!
Thanks for the bug report. Can you please file this as a bug?
There is a very high probability that I introduced a change that
leads to the failure [1] - even if this is fixed now there is a
high probability that it will fail again when [2] is merged.
The reason is, that there are no
Hello!
Thanks Greg for sharing your thoughts. The idea of splitting off DIB
from OpenStack is new for me, therefore I collect some pros and
cons:
Stay in OpenStack:
+ Use available OpenStack infrastructure and methods
+ OpenStack should include a possibility to create images for ironic,
VMs
Hello Ian,
I think I found a regression: since [1] only the first
package specified using '-p' is picked up.
You can find a proposal for a fix under [2].
Maybe it's worth to include this in V2?
Kind regards
Andre
[1] https://review.openstack.org/#/c/396702
[2]
Hello!
> The end result of this would be we have distro-minimal which depends on
> kernel, minimal-userspace, and yum/debootstrap to build a vm/baremetal
> capable image. We could also create a distro-container element which
> only depends on minimal-userspace and yum/debootstrap and creates a
>
Hello!
Looks that you are testing a somewhat uncommon combination ;-)
The error points into the direction that Ubuntu Xenial for arm does
not supply a 'grub-pc' package [1].
Would be good if you could file a ticket.
Kind regards
Andre
[1]
Hello Paul,
thank you very much for your contribution - it is very appreciated.
You addressed a topic with your patch set that was IMHO not in a wide
focus: generating images for containers. The ideas in the patches are
good and should be implemented.
Nevertheless I'm missing the concept
Hi!
Very good proposal. Like to join.
Hopefully we find a time slot - I have no idea where
in the world (and in which timezone) you are all living.
I personally would go for a separate meeting and not
be part of the TripleO meeting - at least for the first
some times.
Kind regards
Andre
Hello Jay,
Yes - the partition alignment is a problem:
grub2 needs at least 63 blocks between the MBR and the first
partition. Here for you the partition directly starts at block 1,
therefore grub has no way to put its data on the disk.
The root cause is, that all the partitioning tools I found
Hi!
Before things getting said twice (looks that there is some
public interest here ;-) ):
Can you please rerun and skip the partition part of
the loop device for fdisk -l?
E.g. instead of /dev/loop0p1 just /dev/loop0?
(This was my original intend but maybe not correctly
described.)
Also can
Hello Tony,
it's already implemented twice :-)
[1] is mostly exactly what your propose (except of the removal of
sfdisk). The problems with this kind of patches:
* If you want to do it somewhat general (i.e. allow more than
one disk partition) the changes are getting (too) big.
* It is not
Hi!
> ++, but one clarification: We do have a spec process which is to use the
> tripleo-specs repo. Since this is obviously not super clear and there is
> a SnR issue for folks who are only dib core maybe we should move specs
> in to the dib repo?
Good to know!
I'd really love to use the dib
Hi!
Created a first draft of a 'Big Picture' document including an overview
and a technical breakdown [1].
I'm not sure if this is what you expect or if still something is
missing?
Maybe we can start with etherpad - and do the first some iterations
there. Later on I'd like to see it moved to the
Hello!
Currently I'm working on diskimage-builder.
My long term goal is, to add some functionality to the DIB's block
device layer, like to be able to use multiple partitions, logical
volumes and mount points.
Initially I created a general partitioning element [1] and based on
this an
Hi All!
AFAIK the diskimage-builder started as a testing tool, but it looks
that it evolves more and more into a general propose tool for creating
docker and VM disk images.
Currently there are ongoing efforts to add LVM [1]. But because some
features that I need are missing, I created my own
14 matches
Mail list logo
