Partitions presented to instance should be ext3, not ext2

[Thierry Carrez]

UEC setup based on 20091020.3 / 1.6~bzr931-0ubuntu7
Booting c1.medium UEC images, I notice the following:

i386 image:
/etc/fstab has "/dev/sda2 /mnt ext3"
Instance is provided with:
  /dev/sda2: Linux rev 1.0 ext2 filesystem data
This results in failure to mount at boot, with messages like "ext3: No journal on filesystem on sda2"

amd64 images:
/etc/fstab has "/dev/sdb /mnt ext3"
Instance has the following device:
  /dev/sda2: Linux rev 1.0 ext2 filesystem data
This results in failure to mount at boot, with messages like "/mnt: waiting for /dev/sdb"

To be compliant with what EC2 does, Eucalyptus should provide instances with ext3 filesystems, not ext2.

[Dustin Kirkland  (kirkland)]

I see the same thing in my amd64 guests.

:-Dustin

[Thierry Carrez (ttx)]

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

[Dustin Kirkland  (kirkland)]

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.

[Dustin Kirkland  (kirkland)]

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.

[Dustin Kirkland  (kirkland)]

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

[Daniel Nurmi (nurmi)]

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.

[Dustin Kirkland  (kirkland)]

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

[Dustin Kirkland  (kirkland)]

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

[Thierry Carrez (ttx)]

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

[Dave Walker (davewalker)]

Is sfdisk able to help here?

[graziano obertelli (graziano.obertelli)]

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.

[Andy Grimm (agrimm)]

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

Please watch that issue for further updates.