Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Disk Druid and other partitioning utilities totally FUBAR|
|Product:||[Retired] Red Hat Linux||Reporter:||Michal Jaegermann <michal>|
|Component:||anaconda||Assignee:||Jeremy Katz <katzj>|
|Status:||CLOSED WONTFIX||QA Contact:||Mike McLean <mikem>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-10-04 22:28:29 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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.