Partitions presented to instance should be ext3, not ext2

I see the same thing in my amd64 guests.

:-Dustin

As long as bug 458850 is fixed (and /mnt gets automounted on UEC instances) fixing this is of lower importance.

Assigning to Dan. He's going to do a bit of testing on this one, and if it works, just commit it upstream, and I'll pull it in the next merge.

Looking at the code, we're actually doing ext3 now, so this might actually be "Fix Released". We need to re-test this on a current Lucid setup.

Targeting at A3 for now, as we should test this and confirm the fix by then.

This turns out to be a bit deeper of an issue than anticipated; we're using parted to create a partition/filesystem during image conversion time for KVM. parted currently does not support the creation of an ext3 partition using mkpartfs (and, since the partition is in the middle of the disk image, we cannot use 'mkfs.ext3'/etc since these tools do not support offsets). We're avoiding the use of loopback devices to mitigate the chances of hitting a race (no atomic 'get a free and attach loopback device). We're looking into this problem in order to determine if there is solid mechanism for creating an ext3 filesystem in the middle of a large disk file.

Dan says that this is not going to be fixed in 1.6.2, so this will probably not make Lucid.

Hmm, we need to somehow mark it won't-fix against Lucid, but leave it
triaged against Lucid+1...

That's the way to do it :)
Mark wontfix the Lucid task, keep open the general task.

Is sfdisk able to help here?

To get this working we should change
   parted mkpartfs primary ext2 start end
to
   parted mkpart primary ext2 start end

and do something like

   dd if=/dev/zero of=temp_part count=1 seek=(end-start-1)
   mkfs.ext3 -F temp_part
   dd if=temp_part of=disk skip=start count=end-start

Tagging for 2.0.4 if we can make it.

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2666

Please watch that issue for further updates.