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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
