Bug 70477 - ks install formats swap partition not mentioned in ks file
Summary: ks install formats swap partition not mentioned in ks file
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lehman
QA Contact: Mike McLean
URL:
Whiteboard:
: 218929 441948 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-08-01 17:12 UTC by Alexandre Oliva
Modified: 2015-02-18 13:33 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-18 13:33:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
anaconda patch (3.11 KB, patch)
2007-08-15 13:48 UTC, Joel Andres Granados
no flags Details | Diff
kickstart diff (3.52 KB, patch)
2007-08-15 13:53 UTC, Joel Andres Granados
no flags Details | Diff
Ignore swap devices at install time. (4.41 KB, patch)
2007-08-21 17:21 UTC, Joel Andres Granados
no flags Details | Diff
polished kickstart patch. (3.67 KB, patch)
2007-08-23 16:37 UTC, Joel Andres Granados
no flags Details | Diff
Polished anaconda patch (4.24 KB, patch)
2007-08-23 16:39 UTC, Joel Andres Granados
no flags Details | Diff

Description Alexandre Oliva 2002-08-01 17:12:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722

Description of problem:
Given an already-installed system with a (RAID5) partition for swap, if you do a
kickstart install on unused partitions telling it *not* to use any swap, it
still formats and uses the existing swap partition, and prints an error message
about an invalid mount point suggesting it's going to reboot.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Install a system with a RAID5 partition for swap (perhaps its being RAID5 is
not critical, but I couldn't duplicate the problem on a machine that didn't have
swap on raid)
2.Create empty ext3 filesystems on hdg1 and hdg5 (or elsewhere), with enough
space to hold a new installation, with labels `l/boot' and `l/', respectively.
3.Create a kickstart file with only the following entries for partitions:
part / --fstype ext3 --noformat --onpart hdg5
part /boot --fstype ext3 --noformat --onpart hdg1
4.Install using this kickstart file

Actual Results:  /etc/fstab of the new install lists /dev/md2 (the swap
partition) for swap.  In an interactive kickstart install, it even asks for
permission to format the swap partition.  It also displays an error window
complaining that mount points are not supposed to contain slashes.  I've
verified it is not caused by the labels of the partitions I've created in the
pre-existing partitions, so I suspect it's related with the swap partition.

Expected Results:  If I didn't tell it to use the swap partition, it shouldn't.
 (think Plex86 or VMware, for example).  The error message doesn't make sense,
and should probably not be given in this case.

Additional info:

Comment 1 Jeremy Katz 2002-08-02 20:18:01 UTC
We currently always format all swap partitions and have been doing for as long
as this partitioning code has been used (7.2) and it matches the behavior of
before.  The invalid mountpoint bit sounds a little weird, though and I'll look
into that

Comment 2 Alexandre Oliva 2002-08-02 20:30:46 UTC
Whether we've always done it or not, I don't think it's correct to format a
partition that was not mentioned in the kickstart file.  Besides, I had
installed my 7.3 boxes using kickstart files like those I use now, in which a
post-install script added /dev/md2 swap to /etc/fstab, and I didn't get
duplicates back then.  Could this be just because the installer didn't
auto-detect RAID5 swap partitions, so it behaved better because of a limitation?

Comment 3 Jeremy Katz 2002-08-02 20:35:07 UTC
Yes, you just got lucky in that you were using RAID'd swap unlike most people
who just use multiple swap devices.

Comment 4 Eugene Kanter 2002-08-06 20:51:40 UTC
> > System has several disks. Selected automatic partitioning and left only
> > one disk checked. Resulting screen says that anaconda will format SWAP
> > areas located on all other disks.
> 
> This has been a characteristic of anaconda for the last few releases. 
> I've let it go both ways; it does mark all swap partitions on the system
> for formatting & use, but no problem if you let it go & use them.
> 

Well, this does not seem like a proper behavior. I remember now that
after utilizing all swap partitions and removing some unused disks I was
getting error messages about some swap partitions not been awailable.

Now, since there is a screen which lets user select disks use for installation
anaconda no way should go beyond selected disks looking for anything at all.

Comment 5 Bob Cochran 2003-10-15 02:07:09 UTC
I am having this problem also in relation to current Fedora Core testing. The 
partitioning code will automatically format any existing swap partitions found. 
I do not think anaconda should format swap partitions belonging to another 
system. I've also noticed while playing with other Linux distros that anaconda 
would format swap created by Debian 3.0R1. Since anaconda does not "know" the 
formatting scheme used by another distribution for swap, (even though the 
partition type may be 'Linux swap') it should not utilize swap that is on 
another physical drive or another partition. 

Comment 6 Alexandre Oliva 2003-10-15 17:19:41 UTC
It's actually not that simple.  There are legitimate reasons to have multiple
swap partitions in multiple disks.  Formatting them, or even offering to format
them, is legitimate and correct behavior IMHO, but formatting them when the user
explicitly left them out of the list of partitions to be formatted is incorrect.

Comment 7 Need Real Name 2003-11-07 20:15:33 UTC
I think I am having this same problem, except my swap partition is for
a RedHat 8.0 system I have installed on another disk. I specifically
unchecked the 'format' flag for the swap partition, yet anaconda still
reformatted it and used it for my Fedora install. Now I can no longer
boot my RedHat 8.0 partition anymore. I suspect this is because of the
reformat. How can I fix this?


Comment 8 Jeremy Katz 2004-10-05 02:45:58 UTC
Should be better now.

Comment 9 Alexandre Oliva 2005-04-18 18:55:17 UTC
anaconda still formats and configures any swap partitions it can find (as
opposed to using only those listed in the kickstart file), and it doesn't
respect the order of swap partitions listed in the kickstart file, which can
often be quite important for performance.

Comment 10 Alexandre Oliva 2006-01-13 15:37:28 UTC
Anaconda still takes all swap partitions it finds and enables them for swap in
the install image.  This is more and more of a problem now, as Xen installs will
then fight for swap devices.

Comment 11 Red Hat Bugzilla 2007-02-05 19:30:04 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 12 Chris Lumens 2007-08-08 20:35:29 UTC
*** Bug 218929 has been marked as a duplicate of this bug. ***

Comment 13 Joachim Schröder 2007-08-09 06:03:45 UTC
Oh, good to see that I am not alone with this problem.
This bug is the reason why I can't move my XEN homeserver from SuSE to RHEL5 
just because our installer can't cope with the existing swap partitions of the 
guests...

Honestly, I do not understand at all why this bug is being ignored for 2 years 
now (since Jeremy claimed it to be fixed).

As Alexandre mentioned, we will see that more and more in the future with 
virtual environments where the installer has to cope with different swap 
partitions that do not belong to the host system.

Comment 14 Joel Andres Granados 2007-08-13 16:27:04 UTC
>/etc/fstab of the new install lists /dev/md2 (the swap
>partition) for swap.  In an interactive kickstart install, it even asks for
>permission to format the swap partition.  It also displays an error window
>complaining that mount points are not supposed to contain slashes.  I've
>verified it is not caused by the labels of the partitions I've created in the
>pre-existing partitions, so I suspect it's related with the swap partition.

Anaconda did not ask if it could format the partition, it just did.  Did not
display an error window complaining about the slashes.  I think these issues are
not relevant anymore (if you have this behavior post the logs).
Going to see if I can make the snake touch only what the user tells it to :)

Comment 15 Joel Andres Granados 2007-08-15 13:46:51 UTC
Proposed solution. a ignoreswapdev line in the kickstart file.  In this way the
user can determine what swap partitions will not be tampered with (not mounted
during install and not included in the fstab).  Patches attached :)

Comment 16 Joel Andres Granados 2007-08-15 13:48:27 UTC
Created attachment 161357 [details]
anaconda patch

puts a list in the PartedUtils.py file that holds all the device names that the
user does not want to touch.  When swap is mounted in the fsset.py file
function turnOnSwap, all the swap devs that are in said list will be ignored. 
The same thing happens when the fstab is being created.

Comment 17 Joel Andres Granados 2007-08-15 13:53:49 UTC
Created attachment 161359 [details]
kickstart diff

Basically adds another option.
this option is ignoreswapdev devs=[dev1,dev2...]

Comment 18 Joel Andres Granados 2007-08-21 17:21:04 UTC
Created attachment 161992 [details]
Ignore swap devices at install time.

Well guess the first patch didn't make it.  Lets see if this one has more
effect :)  I stoped touching pykickstart and put everything in kickstart.py.

Comment 20 Joel Andres Granados 2007-08-23 16:37:03 UTC
Created attachment 169502 [details]
polished kickstart patch.

Comment 21 Joel Andres Granados 2007-08-23 16:39:29 UTC
Created attachment 169503 [details]
Polished anaconda patch

Comment 22 Joel Andres Granados 2008-01-31 16:41:15 UTC
The patch works but after taking a minute, I think its not a good idea to
introduce yet another ks argument.  Looking for alternative solution.

Comment 23 Joel Andres Granados 2008-05-07 10:24:32 UTC
*** Bug 441948 has been marked as a duplicate of this bug. ***

Comment 24 Bug Zapper 2008-05-14 01:55:03 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 25 Bug Zapper 2009-06-09 21:57:17 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 26 Bug Zapper 2009-07-14 17:00:56 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 27 Chris Lumens 2010-06-16 14:12:11 UTC
*** Bug 603344 has been marked as a duplicate of this bug. ***

Comment 28 Adam Williamson 2010-06-21 22:12:03 UTC
Chris, this bug was marked WONTFIX on the basis that it's old. If you're going to mark a report against F13 as being a dupe of this bug, it would make sense to re-open this one =)

Our default behaviour seems really incoherent here; even though we aggressively assume we can use all existing swap partitions as swap for the Fedora install, we *also* default to creating a new swap partition as part of the partitioning scheme (see http://www.dedoimedo.com/computers/fedora-13.html ). This doesn't seem to make much sense. Either creating a new swap partition and just using that, or using any existing swap partitions but *not* creating a new one, would seem to be more consistent behaviours.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 29 Steve Scheider 2010-06-22 00:12:13 UTC
Thanks, Adam.  I was a bit confused when Chris referenced this bug and it had a status of WONTFIX.  
I believe that Fedora should only format and use that swapspace allowed for it.  In the end I had to edit fstab to remove the additional swap fs's, which may not seem like much, but I view it as "planned re-work", which I try to eliminate.
I like the suggestion of a "allow/don't modify" permissive on a given swap partition that the user can set to disallow using a given swap partition.
Thanks,
Steve

Comment 30 Jeff Raber 2010-07-14 16:44:45 UTC
Bumped version to 13, as F9 has been EOL for quite a while now.

Comment 31 David Lehman 2010-12-21 18:15:40 UTC
*** Bug 218929 has been marked as a duplicate of this bug. ***

Comment 32 Fedora End Of Life 2013-04-03 19:52:07 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 33 Fedora End Of Life 2015-01-09 21:35:14 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 34 Fedora End Of Life 2015-02-18 13:33:36 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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