There appears to be lots of different interpretations that's the
problem. That article was the best description I've found of the
process.
The 63s definition comes from 'partition2disk' as used in the UEC
Eucalyptus implementation. That's the main reason I went with that.
There may be an off by one error as admittedly I didn't examine the
partition addition code to see if it started at 0 or 1. (vmbuilder
starts at 0).
I'm entirely comfortable with any higher number that gives maximum
compatibility with msdos partition tools and also the GPT conversion
and GPT partitioning tools.
On 10 December 2010 13:02, Alex Bligh <email address hidden> wrote:
> I'm not sure that's right. Firstly, partitions are meant to be cylinder aligned (per the original DOS specs). sfdisk etc. will refuse to write partition tables unless they are, unless --force is specified. Secondly, fdisk and other utilities are now (when they can read the geometry) creating 1Mb minimum MBR gaps - See (e.g.)
> ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.18/v2.18-ReleaseNotes (under fdisk)
> http://www.spinics.net/lists/util-linux-ng/msg03405.html
>
> You have only created a 62 sector gap (63 sectors less one for the MBR),
> i.e. 31kb, which isn't going to be enough for grub2 by your own article
> (though I am not sure where the 32kb number comes from here). Last time
> I checked, default Ubuntu was putting in a whole cylinder. I accept that
> most of the reason for cylinder aligning partitions is so that CHS
> loaders can work, and because whacky MS copy protection schemes write
> data to the first cylinder, and on virtual machines these are not going
> to be an issue most of the time, but it seems we are at least holding
> ourselves a hostage to fortune with grub2 having less than 32kb.
>
> Does parted not use a 1 cyl default when it is told the geometry?
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/578199
>
> Title:
> ubuntu-vm-builder builds images with no post-MBR gap
>
There appears to be lots of different interpretations that's the
problem. That article was the best description I've found of the
process.
The 63s definition comes from 'partition2disk' as used in the UEC
Eucalyptus implementation. That's the main reason I went with that.
There may be an off by one error as admittedly I didn't examine the
partition addition code to see if it started at 0 or 1. (vmbuilder
starts at 0).
I'm entirely comfortable with any higher number that gives maximum
compatibility with msdos partition tools and also the GPT conversion
and GPT partitioning tools.
On 10 December 2010 13:02, Alex Bligh <email address hidden> wrote: kernel. org/pub/ linux/utils/ util-linux- ng/v2.18/ v2.18-ReleaseNo tes (under fdisk) www.spinics. net/lists/ util-linux- ng/msg03405. html /bugs.launchpad .net/bugs/ 578199
> I'm not sure that's right. Firstly, partitions are meant to be cylinder aligned (per the original DOS specs). sfdisk etc. will refuse to write partition tables unless they are, unless --force is specified. Secondly, fdisk and other utilities are now (when they can read the geometry) creating 1Mb minimum MBR gaps - See (e.g.)
> ftp://ftp.
> http://
>
> You have only created a 62 sector gap (63 sectors less one for the MBR),
> i.e. 31kb, which isn't going to be enough for grub2 by your own article
> (though I am not sure where the 32kb number comes from here). Last time
> I checked, default Ubuntu was putting in a whole cylinder. I accept that
> most of the reason for cylinder aligning partitions is so that CHS
> loaders can work, and because whacky MS copy protection schemes write
> data to the first cylinder, and on virtual machines these are not going
> to be an issue most of the time, but it seems we are at least holding
> ourselves a hostage to fortune with grub2 having less than 32kb.
>
> Does parted not use a 1 cyl default when it is told the geometry?
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https:/
>
> Title:
> ubuntu-vm-builder builds images with no post-MBR gap
>
--
Neil Wilson