Bug 163582

Summary: swap entry in fstab corrupted when swap is installed to md RAID
Product: [Fedora] Fedora Reporter: Anchor Systems Managed Hosting <managed>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Mike McLean <mikem>
Severity: high Docs Contact:
Priority: medium    
Version: 4   
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: 2005-07-19 15:00:20 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 Anchor Systems Managed Hosting 2005-07-19 07:13:52 UTC
*** Bug 163584 has been marked as a duplicate of this bug. ***

Comment 1 Anchor Systems Managed Hosting 2005-07-19 07:14:29 UTC
*** Bug 163585 has been marked as a duplicate of this bug. ***

Comment 2 Anchor Systems Managed Hosting 2005-07-19 07:15:03 UTC
*** Bug 163586 has been marked as a duplicate of this bug. ***

Comment 3 Anchor Systems Managed Hosting 2005-07-19 07:16:40 UTC
Sorry for the duplicates, there was a problem submitting. Here is the text of
the bug:

I am installing a machine with two SCSI hard drives in RAID1. We create all of
the system partitions on RAID1, and place the swap partition on one of the md
devices. In previous Fedora Core and RHEL releases this has worked fine. In FC4
I check the /etc/fstab file immediately after install but before reboot and see
this entry for the swap partition:

LABEL=Y¥W¥X¥ç¨      swap                    swap    defaults        0 0

After reboot, something decides it is a corrupt entry and removes it, thus
leaving the system after reboot without any swap partition at all. Installing to
a single disk without RAID does not have the same problem. I do notice however
that FC4 is now attempting to "intelligently" label the swap partition so
perhaps the logic behind this naming is at fault.

Comment 4 Chris Lumens 2005-07-19 15:00:20 UTC

*** This bug has been marked as a duplicate of 159087 ***