Bug 58569

Summary: Disk Druid and other partitioning utilities totally FUBAR
Product: [Retired] Red Hat Linux Reporter: Michal Jaegermann <michal>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED WONTFIX QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-05 02:28:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Michal Jaegermann 2002-01-20 02:01:56 UTC
Description of Problem:

Partitioning utilities in installer are not really fit for ANY serious
use on Alpha.  It is assumed that installation is done on a machine
with SRM firmware which is purportedly the only type supported by
this distribution.

1)  If on a disk there is an existing FAT partition (quite common
    occurence if disk is "recycled" from some other machine) then Disk
    Druid quietly writes new FAT partition table, especially with an
    automatic partitioning, and after an installation the disk is

2) If first 2 MB of a disk were overwritten with zeros to erase traces
   of old partition tables and "Manually partitio with Disk Druid" is
   chosen then Disk Druid creates a FAT partition table, which is not
   obvious until sufficient number of partitions is created to get
   "logical" partitions, and after an installation the disk is

3) If there is no old FAT partition table and "automatic partitioning"
   is picked up then Disk Druid creates a correct "disklabel type"
   partition table and after an installation the disk is unbootable.

   To make matter worse a non-expert will likely miss on Disk Druid
   display that no space was left for a boot block and even if s/he
   will catch up that things are wrong this is not easy to correct
   as partition table, which could be edited, is written only much
   later when file systems are formatted and then it is too late to
   go back.  Moreover Disk Druid does not offer any means to correct
   that directly as only size can be specified and not starting cylinder.
   One has to know enough to edit this table with fdisk using sector
   units as Disk Druid created partitions do not start on cylinder

4) 'fdisk' offers as a default starting point for the first partition,
   and any other one for that matter, cylinder 1 and if a user will
   fall in this trap then after an installation the disk is

5) If for whatever reasons one would really want a FAT partition table
   on a disk (say installing for a machine which _has_ to be booted
   via "unsupported" milo or any other reason) on which previously a
   disklabel existed then, despite an advertised 'r' command the
   supplied version of fdisk will get confused in no time at all and
   it will claim that there is no space for a new partition on a disk
   totally devoid of partitions of any kind.

Probably the most convenient way with supplied tools is to write the
lowest partition with fdisk making sure that it is of right type and
add the remaining ones using Disk Druid.  Hardly obvious or "user
friendly".  Even there Disk Druid comes with a proposition which
suddenly allows to specify a partition in terms of cylinders, where
this is totally unneded, but the upper end is off-by-one and reaches
beyond available disk space.  Exciting!  Luckily Disk Druid rejects
its own proposition so one would think that we do not end with
a partition table which wraps.  Unfortunately using "New" Disk
Druid creates a partition table where the last partiotion ends on
sector 40132502 on a disk which advertises only 40131504 sectors.
Scratch that idea!

After writing with a help of fdisk a correct partition table with
a layout
"Disk setup" screen insists that we really have
This, surprisingly enough, can be edited but how these things were
derived it is really hard to guess.

It is also possible to "rescue" a botched installation by booting
from the first time from a floppy.  If an "automatic partitioning"
was used then one can save a content of /boot, repartition and recreate
it in a smaller size, and write a boot block with 'swriteboot'.
Hardly an operation for novices.  This assumes that we are able to
fix "wrap" as well which may, or may not, be possible.

Comment 1 Jeremy Katz 2004-10-05 02:28:29 UTC
alpha isn't supported anymore.