Bug 58569 - Disk Druid and other partitioning utilities totally FUBAR
Disk Druid and other partitioning utilities totally FUBAR
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.3
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-19 21:01 EST by Michal Jaegermann
Modified: 2007-04-18 12:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-04 22:28:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2002-01-19 21:01:56 EST
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
    unbootable.

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
   unbootable.

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
   boundaries.

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
   unbootable.

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
  ext2
  swap
  ext2
"Disk setup" screen insists that we really have
  ext2
  ext2
  Foreign
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-04 22:28:29 EDT
alpha isn't supported anymore.

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