Bug 688652 - The image creation process puts the first partition on sector 1 instead of cylinder 1
The image creation process puts the first partition on sector 1 instead of cy...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: releng (Show other bugs)
5.5
All Linux
high Severity high
: rc
: ---
Assigned To: Jay Greguske
Release Test Team
: EC2
Depends On:
Blocks: 692224
  Show dependency treegraph
 
Reported: 2011-03-17 12:08 EDT by Pierre Carrier
Modified: 2011-06-08 11:19 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 692224 (view as bug list)
Environment:
Last Closed: 2011-06-08 11:19:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Untested patch for appliance-tools. Hope it can help. (1.70 KB, patch)
2011-03-21 05:12 EDT, Pierre Carrier
no flags Details | Diff

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.