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

[Kees Cook]

parted uses a fixed sector count of "32" when writing partitions to a non-block device. (See init_file() via linux_new() in libparted/arch/linux.c) As a result, the track size of disks created with vmbuilder is 32 sectors, not the generally expected 63 sectors (used with LBA mode). This means that the "embedding region" between the end of the MBR and the start of partition 1 is half the "normal" size, and grub2 will not install.

/usr/sbin/grub-setup: warn: Your embedding area is unusually small. core.img won't fit in it..

Fastest solution I see is to use an environment override as already done in init_file() for sector size. Perhaps PARTED_SECTORS? And then set this to 63 when calling parted from vm-builder.

[Marc Deslauriers (mdeslaur)]

I get this also.

[Kees Cook (kees)]

Incorrect but functional hack attached...

[Launchpad Janitor (janitor)]

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

[Phillip Susi (psusi)]

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?

[Kees Cook (kees)]

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.

[Phillip Susi (psusi)]

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.

[Kees Cook (kees)]

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.

[Phillip Susi (psusi)]

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.

[geaplanet (geaplanet)]

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.

[David Scherfgen (d-scherfgen)]

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"

[Will Bryant (willbryant)]

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?