Bug 51637 - fdisk creation of swap doesn't work
fdisk creation of swap doesn't work
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.3
i386 Linux
high Severity high
: ---
: ---
Assigned To: Brent Fox
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-13 10:16 EDT by Chris Ricker
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-15 18:01:07 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 Chris Ricker 2001-08-13 10:16:10 EDT
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 11:13:15 EDT
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 11:24:17 EDT
Very similar to bug 51349.
Comment 3 Glen Foster 2001-08-13 15:09:46 EDT
This defect is considered SHOULD-FIX for Fairfax.
Comment 4 Michael Fulbright 2001-08-20 11:10:24 EDT
This should be handled more sanely in RC1.

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