Bug 1020867 - kickstart --noformat swap not added to /etc/fstab
Summary: kickstart --noformat swap not added to /etc/fstab
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 20
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F20BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2013-10-18 12:06 UTC by Gene Czarcinski
Modified: 2015-06-30 01:33 UTC (History)
12 users (show)

Fixed In Version: anaconda-20.25.2-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-30 01:33:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
fix swaps in anaconda-20.25.1 (1.37 KB, patch)
2013-10-18 19:24 UTC, Gene Czarcinski
gczarcinski: review+
Details | Diff

Description Gene Czarcinski 2013-10-18 12:06:20 UTC
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

How reproducible:
every time (tested with KVM virtuals)

Comment 1 Gene Czarcinski 2013-10-18 14:18:17 UTC
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.

Comment 2 Gene Czarcinski 2013-10-18 14:29:35 UTC
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.

Comment 3 Gene Czarcinski 2013-10-18 16:45:16 UTC
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.

Comment 4 Gene Czarcinski 2013-10-18 19:24:25 UTC
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.

Comment 5 Gene Czarcinski 2013-10-18 23:04:08 UTC
i have posted some updates img files at http://czarc.net/

Comment 6 Adam Williamson 2013-10-21 15:46:00 UTC
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'...

Comment 7 Gene Czarcinski 2013-10-21 16:42:48 UTC
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.

Comment 8 Mike Ruckman 2013-10-21 17:09:23 UTC
Discussed this in 2013-10-21 Blocker Review Meeting [1]. 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.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-21/

Comment 9 Adam Williamson 2013-11-06 18:11:46 UTC
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.

Comment 10 Gene Czarcinski 2013-11-07 18:07:06 UTC
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.

Comment 11 Gene Czarcinski 2013-11-07 19:06:41 UTC
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.

Comment 12 Gene Czarcinski 2013-11-07 22:20:32 UTC
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.

Comment 13 Adam Williamson 2013-11-07 23:13:14 UTC
git://git.fedorahosted.org/blivet.git

Comment 14 Gene Czarcinski 2013-11-08 02:53:44 UTC
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.

Comment 15 Fedora End Of Life 2015-05-29 09:35:36 UTC
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'
of '20'.

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.

Comment 16 Fedora End Of Life 2015-06-30 01:33:33 UTC
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
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.