Bug 688652

Summary: The image creation process puts the first partition on sector 1 instead of cylinder 1
Product: Red Hat Enterprise Linux 5 Reporter: Pierre Carrier <prc>
Component: relengAssignee: Jay Greguske <jgreguske>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team-automation>
Severity: high Docs Contact:
Priority: high    
Version: 5.5CC: dgregor, dmach, jfenal, jgreguske, jwest, prc, tkopecek, whayutin
Target Milestone: rcKeywords: EC2
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 692224 (view as bug list) Environment:
Last Closed: 2011-06-08 15:19:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 692224    
Attachments:
Description Flags
Untested patch for appliance-tools. Hope it can help. none

Description Pierre Carrier 2011-03-17 16:08:04 UTC
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.

Comment 1 Pierre Carrier 2011-03-21 09:12:23 UTC
Created attachment 486573 [details]
Untested patch for appliance-tools. Hope it can help.

Comment 3 Pierre Carrier 2011-03-22 21:59:26 UTC
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):

Comment 6 Daniel Mach 2011-04-06 06:59:25 UTC
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

Comment 7 Jay Greguske 2011-04-06 12:52:04 UTC
Thanks for the heads' up, will check into it today. (and RHEL 6)

Comment 8 Jay Greguske 2011-04-06 15:26:46 UTC
Urk. Reverting the RHEL 5 buildroots. RHEL 6 is ok.

Comment 9 Jay Greguske 2011-06-08 15:19:54 UTC
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.