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:
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
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?
Yes, you just got lucky in that you were using RAID'd swap unlike most people who just use multiple swap devices.
> > 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.
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.
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.
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?
Should be better now.
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.
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.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
*** Bug 218929 has been marked as a duplicate of this bug. ***
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.
>/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 :)
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 :)
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.
Created attachment 161359 [details] kickstart diff Basically adds another option. this option is ignoreswapdev devs=[dev1,dev2...]
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.
Created attachment 169502 [details] polished kickstart patch.
Created attachment 169503 [details] Polished anaconda patch
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.
*** Bug 441948 has been marked as a duplicate of this bug. ***
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
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
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.
*** Bug 603344 has been marked as a duplicate of this bug. ***
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
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
Bumped version to 13, as F9 has been EOL for quite a while now.
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
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.
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.