Bug 51637

Summary: fdisk creation of swap doesn't work
Product: [Retired] Red Hat Linux Reporter: Chris Ricker <chris.ricker>
Component: anacondaAssignee: Brent Fox <bfox>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: high    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-08-15 22:01:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Chris Ricker 2001-08-13 14:16:10 UTC
New install using GUI installer (used fdisk to write empty partition tables
to disks before starting install)

Using fdisk, I created partition tables on two drives, including a swap
partition which I made type 0x82.

anaconda then brought up disk druid to label the partitions, where the swap
partition was correctly recognized as swap.  I mkfs'ed and set mount points
for all the 0x83 partitions, and did nothing with the swap partition.

When I hit next, a warning popped up about no swap being available.  I was
only able to get it to recognize the correctly created swap partition by
hitting back and changing the type of swap to ext3 and then back to swap.

After doing that (which I shouldn't have had to do -- it's highly
non-intuitive), the installer died with "a serious error initializing swap".

I was finally only able to get install to proceed by starting over from
scratch, creating swap in fdisk, telling anaconda to proceed without swap,
and manually running mkswap, swapon, and adding an entry for swap to
/etc/fstab after the install finished.

The swap partition I created was 512 megs, which certainly isn't
unreasonable.  I have no idea why anaconda choked on it.

Comment 1 Michael Fulbright 2001-08-13 15:13:15 UTC
We have been discussion how to handle your original situation better. The issue
arises because the GNU parted library we are using for partitioning now looks at
the actual filesystem on the partition to determine its 'type'.  This does not
have to match the numeric partition type code stored in the partition table,
which leads to the confusing situation you encountered. There wasn't really room
in the main Disk Druid interface to show both the partition type and the
filesystem type unfortunately.

I am thinking about adding a dialog which pops up when you enter the Disk Druid
screen to report when there is a mismatch of this type. That way the user will
have a better understanding of the situation.



Comment 2 Michael Fulbright 2001-08-13 15:24:17 UTC
Very similar to bug 51349.

Comment 3 Glen Foster 2001-08-13 19:09:46 UTC
This defect is considered SHOULD-FIX for Fairfax.

Comment 4 Michael Fulbright 2001-08-20 15:10:24 UTC
This should be handled more sanely in RC1.