Red Hat Bugzilla – Bug 1020867
kickstart --noformat swap not added to /etc/fstab
Last modified: 2015-06-29 21:33:33 EDT
Description of problem:
With F20 Beta TC5 we have a new little problem: --noformat swap (both regular partitions and logical volumes) are not added to /etc/fstab. However, is a new swap is defined, it is added. This was working with TC4.
Version-Release number of selected component (if applicable):
Fedora 20 Beta-TC5, anaconda-20.25.1-1, python-blivet-0.23.1-1
every time (tested with KVM virtuals)
WTF? I looked at the code in blivet/__init__.py around line 2879 (0.23.1 version) and if in installer mode it appears that swap is being filtered from being added to /etc/fstab.
I am not sure what the objective is but the result is an error.
On line 2888, there is a question as to why the swap partition(s) are listed in /etc/fstab.
I have an answer: so the the system, when booted, can tell what partitions are valid to use for swap and to ignore all other partitions for swap even if they are validly formatted for swap.
I have a situation where I am KVM testing grub2/os-prober for some problems. I have a "regular system defined with a single virtio disk. I have then share-attached additional virtio disks created by other KVM systems. Each of those additional disks also have swap partitions or logical volumes defined. However, I do not want my running system to use any of them.
This problem was not cuase by something in python-blivet 0.23.1 since that is in TC4 and swap was handled correctly there. Something must have changed in anaconda.
Created attachment 813899 [details]
fix swaps in anaconda-20.25.1
There are three and not two possible situations for a swap:
a new partition/logical volume, reformat an existing partition or
logical volume and do not format (--noformat) a partition
or logical volume.
I am in the process of testing this and will provide feedback when complete but eyeball analysis says this is it.
i have posted some updates img files at http://czarc.net/
vpodzime, this change was not proposed or accepted as a blocker or FE issue and shouldn't really be pushed to the frozen branch of anaconda without that happening. I suppose we should discuss it as an FE issue 'retrospectively'...
The described problem and the fix are definitely a blocker for final release ... for the beta, well, it really does not do anything destructive and can be fixed post install and even in a post-install script ... it is just aggravating.
Discussed this in 2013-10-21 Blocker Review Meeting . Accepted as a freeze exception issue as it could cause unwanted behaviour for some configurations and previously used to behave correctly, anaconda team, please try to avoid pushing things to the frozen branch that aren't FE/blocker fixes.
20.25.4-1 went stable as part of FEDORA-2013-20033. Gene, can you verify this is resolved in Beta RC4 or later? Then we can close it. Thanks.
I do not understand it becasue I would swear that the UUID= business for an existing volume was fixed.
Anyway, running on a Fedora-20-Beta host, I used pungi running under mock to create and up-to-date ISO with anaconda-20.25.6-1, pykickstart-1.99.44-1, and python-blivet-0.23.3-1. The --noformat --subvol is in /etc/fstab but with /dev/vda rather than the same UUID=<> as subvol=root has.
Since I seem to be the one with the "reverse midas touch", do you want me to instrument my test (add some pdb.set_trace()) and see if I can tell what is going on? I would rather hand you folks a solution than just a problem. It may be the "wrong" solution and there may be a better or more appropriate one but that will be for you to decide.
OK, let me try this one more time. I added pdb.set_trace() in kickstart.py in the btrfs data as well as in install.py immediately before the first storage.write()
When I started tracing at the storage.write(), I traced through the setting of fstab. Around line 2919 in blivet/__init__.py, the code says:
devspec = device.fstabSpec()
which in turn brings up fstabSpec() in blivet/devices.py around line 676.
It is here that the decision is made about how things will be specified. If device.format exists and device.format.uuid exists, then UUID= is used, otherwise path is used.
My quick and dirty engineering approach is to set device.format.uuid to the parent uuid back in kickstart.py where device.format.mountpoint is set.
The current approach does not appear to be working. I do not know why but I will take a look after my home owners association meeting.
BTW, do not get me wrong. As it now exists it is 110% better than it was because there is an entry in fstab. It can be fixed up post-install.
I see the problem now. David Lehman's patch to python-blivet has net been applied to the python-blivet-0.23.3-1. I will make up an updates disk with the updated rpm and give it a try.
BTW, where is the actual git that you folks update for blivet code, the repository at git://pkgs.fedoraproject.org/python-blivet.git does not have any code in it that I could find.
Oops, with the patch applied to python-blivet, everything comes tumbling down ... anaconda crashes and burns.
I am just an old (literally) engineer. Perhaps the quick and dirty approach should be given another look. It does work afterall; it does not crash the system; and it is simple.
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version'
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 20 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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
Thank you for reporting this bug and we are sorry it could not be fixed.