[openstack-dev] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

Clint Byrum clint at fewbar.com
Tue Jun 21 18:42:18 UTC 2016


Excerpts from Jay Pipes's message of 2016-06-21 14:20:07 -0400:
> On 06/21/2016 02:01 PM, Andre Florath wrote:
> > 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 (like
> > parted or sfdisk) make some 'optimization': they do not what you
> > state but what they think you want. (And I have the impression that
> > their 'thinking' includes the moon phases and the biorhythm of the
> > user :-) .)
> >
> > Example in your case: sfdisk called with '1 - - *' creates on Ubuntu
> > Xenial a partition starting from block 1. On Debian 8.4 (my
> > development machine) it creates a partition starting from 2087.  This
> > gives some room for grub, but it horrible when it comes to alignment.
> >
> > Some possible workarounds:
> > o Use another host for creating the Ubuntu VM
> >    (and hope, that sfdisk behaves 'better'.)
> > o Use a more recent version of diskimage-builder:
> >    some time ago 'sfdisk' was replaced by 'parted'
> >    (and hope, that 'parted' does a 'better' job for you).
> > o Under Ubuntu Xenial execute with 1.0.0 installed:
> >    $ sudo vi /usr/share/diskimage-builder/elements/vm/block-device.d/10-partition
> >    In line 23 replace
> >       1 - - *
> >    with
> >       2048 - - *
> >    (Note that this really only works on Ubuntu Xenial.)
> >
> > Hope this works and helps - was not able to test these things.
> >
> > If you are interested in some more background information:
> > I stumbled over the mostly random behavior of these tools last week.
> > One aspect is, that they optimize things for the current system (e.g.
> > reading some kernel parameters; especially IO buffer sizes).  These
> > sizes can be completely different on the target system - which might
> > lead to very poor disk performance.
> > During the last days I reworked my patch (which originally used
> > parted) to directly write the needed info to the boot records. [1]
> > More details can be found in the comments of MBR.py [2].
> >
> > Kind regards
> >
> > Andre
> 
> Thanks for the great information and help, all! I upgraded dib to 1.17, 
> re-ran the same command et voila, problem solved. :)
> 
> So, looks like parted vs. sfdisk is indeed the issue, and is solved in 
> modern dib versions. (Time to update Xenial's PPA for dib? ;)
> 

Just looks like it hasn't been uploaded in a while:

https://tracker.debian.org/pkg/python-diskimage-builder

Once 1.17+ gets into yakkety (The future Ubuntu 16.10) we can propose it
for xenial-backports.



More information about the OpenStack-dev mailing list