Red Hat Bugzilla – Full Text Bug Listing
|Summary:||ks install formats swap partition not mentioned in ks file|
|Product:||[Fedora] Fedora||Reporter:||Alexandre Oliva <oliva>|
|Component:||anaconda||Assignee:||David Lehman <dlehman>|
|Status:||CLOSED EOL||QA Contact:||Mike McLean <mikem>|
|Version:||19||CC:||awilliam, cochranb, ekanter, jeff.raber, jschrode, keith105, sscheider, stephent98, thethirddoorontheleft, tomek|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-02-18 08:33:36 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Alexandre Oliva 2002-08-01 13:12:02 EDT
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 16:18:01 EDT
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 16:30:46 EDT
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 16:35:07 EDT
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 16:51:40 EDT
> > 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-14 22:07:09 EDT
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 13:19:41 EDT
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 15:15:33 EST
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-04 22:45:58 EDT
Should be better now.
Comment 9 Alexandre Oliva 2005-04-18 14:55:17 EDT
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 10:37:28 EST
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 14:30:04 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 12 Chris Lumens 2007-08-08 16:35:29 EDT
*** Bug 218929 has been marked as a duplicate of this bug. ***
Comment 13 Joachim Schröder 2007-08-09 02:03:45 EDT
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 12:27:04 EDT
>/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 09:46:51 EDT
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 09:48:27 EDT
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 09:53:49 EDT
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 13:21:04 EDT
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 12:37:03 EDT
Created attachment 169502 [details] polished kickstart patch.
Comment 21 Joel Andres Granados 2007-08-23 12:39:29 EDT
Created attachment 169503 [details] Polished anaconda patch
Comment 22 Joel Andres Granados 2008-01-31 11:41:15 EST
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 06:24:32 EDT
*** Bug 441948 has been marked as a duplicate of this bug. ***
Comment 24 Bug Zapper 2008-05-13 21:55:03 EDT
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 17:57:17 EDT
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 13:00:56 EDT
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 10:12:11 EDT
*** Bug 603344 has been marked as a duplicate of this bug. ***
Comment 28 Adam Williamson 2010-06-21 18:12:03 EDT
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-21 20:12:13 EDT
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 12:44:45 EDT
Bumped version to 13, as F9 has been EOL for quite a while now.
Comment 31 David Lehman 2010-12-21 13:15:40 EST
*** Bug 218929 has been marked as a duplicate of this bug. ***
Comment 32 Fedora End Of Life 2013-04-03 15:52:07 EDT
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 16:35:14 EST
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 08:33:36 EST
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.