vmbuilder uses parted to create disk images, which leads to broken sector counts (cannot use grub2 on disk images created by vmbuilder/parted)

I get this also.

Incorrect but functional hack attached...

Status changed to 'Confirmed' because the bug affects multiple users.

Parted defaults to leaving the first 1 MB of the disk empty these days, regardless of the cylinder size. I just tested it by creating a 1 gb file and having parted mklabel msdos, then mkpart using 0% and 100% as the start and end positions, and the partition starts at sector 2048 even though the sector count is 32.

Can you describe how to reproduce the results you describe with parted?

The problem is that parted treats local files (as used by vmbuilder) differently from "actual" disk files, and changes the sector size accordingly (without an option to change it). As a result, the partition start locations are too small for grub2 to install. I had originally reproduced this by using vmbuilder to install Ubuntu, and then attempting to update to grub2, which would fail, since there wasn't enough room.

My previously attached hack/work-around for vmbuilder was to skip a sector when building the first partition.

Ok, I think I see the problem in parted. I assume that vmbuilder uses the output of parted's print free command to decide where to start the new partition, and that shows the free space starts at 16.4kb. Specifying that as the start position for the new partition would result in the too small embed area issue.

Since parted prefers to start the first partition at 1 mb, it should probably report the free space as starting there as well, not at 16.4kb.

Hm, I don't agree. I think the problem is in libparted/arch/linux.c init_file():

        dev->bios_geom.sectors = 32;

vs _device_probe_geometry() which defaults to what the LBA reports or:

        dev->bios_geom.sectors = 63;

So, when vmbuilder uses parted to build the disk, parted treats the disk file differently than it would a real LBA mode drive. Fixing this is the core cause of the problem, as far as I see it.

The bios geometry just shouldn't matter. Sure, it is odd that it uses a different geometry for an image file than a disk, but whether the nonsensical geometry specifies 63 or 32 or 3 sectors per track, partitions are supposed to have a 1mb alignment these days. This is what you get if you specify the start position as 0%, so it doesn't make sense for the free space check to advertise a lower position as a valid start, especially when you get a warning exception when you try to use it, which I guess is ignored by vmbuilder.

Hi! Two years later this bug continues. What is finally the right solution. Pendrives partitioned with parted are impossible to use to install on it linux distributions. GRUB2 don't find free space enough because grub2 tries to be installed on the first track, but the first track have only 32 sectors, not 63!

Actually, it starts on 2048 and grub has space enough for being installed. Grub2 have a --force option that I have used sometimes on Debian, but on Ubuntu doesn't work. It complains about that I have to use -f or -s options using grub-install, but they don't work.

Actually the first partition's start value of "63s" is hardcoded into the script.
Therefore it's easy to change:

Edit /usr/share/pyshared/VMBuilder/disk.py

In line 299, change

partition_start = "63s"

to

partition_start = "2048s"

I could be misunderstanding the problem here, I think we've had trouble with the 32/63 thing in other respects too, such as getting corrupted disk images when someone uses something other than parted (or uses parted but doesn't change the sector size) to resize the partitions.

Would it be worth fixing it both ways?