Bug 47963 - swriteboot fails due to OSF-style overlapping partitions
Summary: swriteboot fails due to OSF-style overlapping partitions
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: aboot   
(Show other bugs)
Version: 7.1
Hardware: alpha
OS: Linux
Target Milestone: ---
Assignee: Matt Wilson
QA Contact: Brock Organ
URL: http://www.linuxdoc.org/HOWTO/SRM-HOW...
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-09 08:16 UTC by Charles R. Anderson
Modified: 2007-04-18 16:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-12 14:59:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Charles R. Anderson 2001-07-09 08:16:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux sparc64; en-US; rv:0.9.2) Gecko/20010702

Description of problem:
During the last stage of the Red Hat 7.0->7.1 upgrade install when the
bootloader is written to disk, it fails with this syslog message:

error: bootcode overlaps with partition #1. If you really want this, use -f1

My partition layout is as follows:

4 partitions:
#       start       end      size     fstype   [fsize bsize   cpg]
  a:        1         1*        0*      boot                      
  b:        1*      244*      242*      swap                      
  c:        1      1940*     1939*    unused        0     0       
  d:      244*     1940*     1696*      ext2                      

Since partitions a (sda1) and c (sda3) overlap for OSF/Tru64 compatibility,
the fix is to specify parameters to swriteboot to allow it to write to
overlapped partitions:

swriteboot -f1 -f3 /dev/sda1 bootlx

I had to boot in rescue mode and execute this command manually in order to
make the system bootable.

How reproducible:
Didn't try

Actual Results:  swriteboot failed during installer.  System was unbootable
after upgrade from RH 7.0 to RH 7.1

Expected Results:  swriteboot should not ever fail to install the bootloader

Additional info:

Computer is a Digital Personal Workstation (Miata) 500au.

Comment 1 Charles R. Anderson 2001-07-09 14:25:34 UTC
I just realized how confusing the BSD partitions are when viewed in cylinder
units.  Here it is again in sector units.  I would highly recommend to anyone
that they use sector units when dealing with BSD disklabels.

4 partitions:
#       start       end      size     fstype   [fsize bsize   cpg]
  a:        0      2047      2048       boot                      
  b:     2048   1050623   1048576       swap                      
  c:        0   8380079   8380080     unused        0     0       
  d:  1050624   8380079   7329456       ext2                      

Comment 2 Brent Fox 2001-07-10 05:03:10 UTC
Phil, any ideas here?

Comment 3 Phil Copeland 2001-07-10 14:35:30 UTC
Yikes, I don't think we support that configuration
Passing over to Matt for comment

Comment 4 Matt Wilson 2001-07-12 14:59:26 UTC
No, aboot would overwrite parts of your 1st partition.  Why do you have a
partition of type "boot"?

Comment 5 Charles R. Anderson 2001-07-23 11:38:50 UTC
The first partition labelled 'boot' is just reserved space for aboot.
It is meant to be overwritten with swriteboot.  When I set this up 
originally, I had Tru64 on the box, and I was following this
HOWTO for how to partition the disk for both Tru64 and Linux:


It explains pretty clearly that 'a' and 'c' MUST start at 0 for
Tru64, and suggests the use of 'a' to be used for aboot.

Given that this HOWTO is out there, and Tru64 requires 'a' and 'c'
to begin at offset 0, shouldn't the Red Hat installer support
this?  If not, the installer should at least check for an unsupported
layout and warn the user.  Maybe you could do both.  When you are about
to do the swriteboot, pop up a dialog box if there are overlapping

"WARNING: Partitions sda1 and sda3 overlap.  Writing the bootloader
could overwrite the data on these partitions.  This may be normal if you
partitioned the disk under Compaq Tru64 UNIX, in which case it is safe
to continue.  Would you like continue writing the bootloader, or skip it

(Continue)         (Skip)"

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