Open Stack

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? ;)

Best,
-jay