Red Hat Bugzilla – Full Text Bug Listing
|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:||releng||Assignee:||Jay Greguske <jgregusk>|
|Status:||CLOSED WONTFIX||QA Contact:||Release Test Team <release-test-team>|
|Version:||5.5||CC:||dgregor, dmach, jfenal, jgregusk, jwest, prc, tkopecek, whayutin|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||692224 (view as bug list)||Environment:|
|Last Closed:||2011-06-08 11:19:54 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Pierre Carrier 2011-03-17 12:08:04 EDT
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 05:12:23 EDT
Created attachment 486573 [details] Untested patch for appliance-tools. Hope it can help.
Comment 3 Pierre Carrier 2011-03-22 17:59:26 EDT
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 02:59:25 EDT
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 08:52:04 EDT
Thanks for the heads' up, will check into it today. (and RHEL 6)
Comment 8 Jay Greguske 2011-04-06 11:26:46 EDT
Urk. Reverting the RHEL 5 buildroots. RHEL 6 is ok.
Comment 9 Jay Greguske 2011-06-08 11:19:54 EDT
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.