Bug 19019 - RFE: Tru64 compatible partitioning
RFE: Tru64 compatible partitioning
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.3
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
Brock Organ
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-13 00:29 EDT by Michal Jaegermann
Modified: 2007-04-18 12:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-10-19 10:21:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2000-10-13 00:29:18 EDT
While using fdisk, even that one broken from anaconda, an "unused"
partition 'c' which covers the whole disk is created.  Quite rightly
so if the disk in question can be seen also by another OS like Tru64.

At the very end of an installation process an error mesage from
"bootconfig:" flashes on screen.  It is hard to catch up because
a machine is immediately rebooting and the error is not, unfortunately,
recorded in any log files.  As far as I can tell it is complaining
that a bootblock will overlap with some partitions (the said 'c')
and fails to write one on a disk with a fresh installation.
It looks to me that '-f3' flag to 'swriteboot' was forgotten.

In case when 'c' does not include an initial disk sector no harm will be
done.  But although booting from such disk is not a very big deal
to me it can be quite frustrating to a newbie.

Additional idea.  It would be quite nice to have in /etc/aboot.conf
on a distribution CD extra entries of this kind:

2:kernels/vmlinux.gz root=/dev/hda1 ro

Say four for hda partitions for sda.  There is a pretty good chance
that a newbie with a missing bootblock could use one of these for
the first boot.  In case none would fit s/he would have at least
some sample boot lines to be displayed by 'l' in aboot.

  Michal
  michal@harddata.com
Comment 1 Michael Fulbright 2000-10-18 18:08:16 EDT
Switch arch to alpha - this doesn't sound like a problem on the i386.
Comment 2 Michal Jaegermann 2000-10-18 19:35:37 EDT
Yes, this is bug on Alpha.  It is quite possible that I forgot to switch
an architecture from a default; or this is an example of bugzilla getting
confused.

I know why I immediately filed up a bug report against bugzilla when
it was introduced.  Unfortunately it was totally ignored.
Comment 3 Brock Organ 2000-10-19 09:43:13 EDT
hi Michal,

does your "whole disk" partition start @ cylinder 1 and end at the last cylinder
...?  If so, perhaps creating the partition starting from cylinder 2 and going
to the last cylinder may workaround this ...?

Our partition tables do not use cylinder 1 (as boot info is stored there).
such as the sample partition table below:

[root@Alpha3 /root]# fdisk -l /dev/hda                                           

Disk /dev/hda: 16 heads, 63 sectors, 39770 cylinders                            
Units = cylinders of 1008 * 512 bytes                                            

8 partitions:                                                                   
#       start       end      size     fstype   [fsize bsize   cpg]              
a:        2      1042      1041       ext2                                      
b:     1043      1563       521       swap                                      
c:     1564      2604      1041       ext2                                      
d:     2605     10927      8323       ext2                                      
e:    10928     19250      8323       ext2                                      
f:    19251     27573      8323       ext2                                      
g:    27574     35896      8323       ext2                                      
h:    35897     39770      3874       ext2                                      
[root@Alpha3 /root]#
Comment 4 Brock Organ 2000-10-19 10:18:49 EDT
my suggestion above probably is wrong: :(

(from the SRM Howto see http://www.alphalinux.org/faq/srm.html)
---------------------------------
Sharing a Disk With DEC Unix

Unfortunately, DEC Unix doesn't know anything about Linux, so sharing a single
disk between the two OSes is not entirely trivial. However, it is not a
difficult task if you heed the tips in this section. The section assumes you are
using aboot version 0.5 or newer.

Partitioning the disk

First and foremost: never use any of the Linux partitioning programs (minlabel
or fdisk) on a disk that is also used by DEC Unix. The Linux minlabel
program uses the same partition table format as DEC Unix disklabel, but there
are some incompatibilities in the data that minlabel fills in, so DEC Unix will
simply refuse to accept a partition table generated by minlabel. To setup a
Linux ext2 partition under DEC Unix, you'll have to change the disktab entry for
your disk. 
Comment 5 Brock Organ 2000-10-19 10:21:30 EDT
Yes, my suggestion above is wrong ... (apologies, Michal!)

(from the SRM Howto see http://www.alphalinux.org/faq/srm.html)

"DEC Unix insists that partition a starts at offset 0 and that partition c spans
the entire disk."
Comment 6 Brock Organ 2000-10-19 12:00:08 EDT
I will mark this as an enhancement request (probably will be deferred until the
next release), and change the Summary info ...

Here is an excerpt from an email from Michal that summarizes the issue well
(thanks!):

Date: Thu, 19 Oct 2000 09:22:32 -0600                                           
From: michal@harddata.com
To: borgan@redhat.com                                                           
Subject: Re: [Bug 19019] Changed - errors in an installation of a boot
block                                            

... <snip> ...

BSD partitioning explicitely allows for overlapping partitions, and             
fdisk follows that specification, although this is not a good idea              
for partitions on which you are storing your data. :-)  This is                 
_different_ than with partition tables of "FAT type" as used on
x86.                                                                                          
'fdisk' actually does that right and maybe a bug report against                 
DiskDruid should be filed if this is one is messing things up?                  
"Tru64 compatible partitioning" should be at least an option.                   
With a "compatible" partition table present an installer indeed                 
screws up and fails to write a boot block while on obstacle is                  
really present.  Still 'swritedisk' is on a cautious side and                   
wants a confirmation that you do know what you are
doing.                                                               

... <snip>

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