Description of problem: - /dev/sda1 starts on sector 1 on EC2 AMIs Version-Release number of selected component (if applicable): RHEL5.5 EC2 AMIs How reproducible: 100% Steps to Reproduce: 1. Build an image from http://cvs.devel.redhat.com/cgi-bin/cvsweb.cgi/utility-scripts/cloud/kickstarts/rhel5-x86_64-AMAZON-STARTER.ks?rev=1.1;content-type=text%2Fplain;cvsroot=RH-RelEng;f=h 2. Boot it 3. sfdisk -uS /dev/sda|grep sda1 Actual results: /dev/sda1 : start= 1, size=..., Id=83 Expected results: /dev/sda1 : start= 12, size=..., Id=83 Additional info: - The space after the MBR in the first track is usually used by grub for stage1.5, which we don't need with EC2 - This breaks fdisk badly if one tries to grow the partition by deleting it and recreating it larger (with a bigger size): Command (m for help): u Changing display/entry units to sectors Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First sector (63-209715199, default 63): 1 Value out of range. First sector (63-209715199, default 63): - I believe this might break block alignment between the ext filesystem and underlying storage if Amazon ever switches to 4KB storage blocks (more and more common), causing a very significant performance drop. - More importantly, if one does not change the unit size in fdisk and "carelessly" keeps the starting position of 1, as appearing in the fdisk -l output and commonly used since the dawn of ages on IBM PC, the system will not boot anymore.
Created attachment 486573 [details] Untested patch for appliance-tools. Hope it can help.
I can confirm the default geometry of a loopback device (as created by livecd-tools through LoopbackMount.loopsetup and therefore used during partitioning) has the same number of sectors per track, 63: # dd if=/dev/zero of=test-disk bs=1M count=10 # modprobe loop; dev=$(losetup -f) # losetup $dev test-disk # fdisk /dev/loop0 [...] Command (m for help): u Changing display/entry units to sectors Command (m for help): n [...] p primary partition (1-4) p Partition number (1-4): 1 First sector (63-20479, default 63):
Jay, the change broke last RHEL-5 nightly: Adding disk sda as ... Extending sparse file ... Losetup add /dev/loop0 mapping to ... Formatting disks Initializing partition table for /dev/loop0 Assigning partitions to disks Assigned / to sda1 at 0 at size 6143 Creating partitions Add primary part at 0 of size 6143 Unable to create appliance : Failed mount disks : Unexpected number of partitions from kpartx: 0 != 1 Losetup remove /dev/loop0
Thanks for the heads' up, will check into it today. (and RHEL 6)
Urk. Reverting the RHEL 5 buildroots. RHEL 6 is ok.
The misbehavior is still present, but we no longer upload disk images to EC2. Instead we upload partition images, which don't have a partition table on them, so this bug no longer affects customers.