Anaconda-devel November 2015

anaconda-devel@lists.stg.fedoraproject.org

16 participants
4 discussions

Notifying post-install tools about screens seen by the user
by Martin Kolman 06 May '16

06 May '16

The idea is that we should not show configuration screens the users has already visited during the installation in post-installation tools, such as Initial Setup and Gnome Initial Setup. An example of such a screen is the timezone spoke - if the user already visited the timezone spoke during the installation it is unlikely to be useful showing it again in IS or GIS. So there should be a way for Anaconda to tell the post-installation tools what screens have been visited by a user during the installation, so that the tools can hide or skip the given screen. While Anaconda already produces a kickstart file after successful installation, the resulting commands in the file don't really map to individual screens and there is no information about what commands have been generated automatically, based on user action or which were part of an initial kickstart file used for the installation. Also parsing a kickstart file in a robust way really requires Pykickstart, which might not be straightforward to use (at least without wrappers) from post -install utilities not written in Python, such as Gnome Initial Setup. Therefore a separate simple configuration file forwarding the needed information about visited screens to post-installation tools is needed. Manual installation description file proposal * use the "INI file like" config file format - can be easily parsed from Python using the configparser module - should be also easy to parse from C and other programming languages due to widespread use of INI files * stored in /etc/anaconda/manual_installation.ini - other name/path suggestions welcome! :) * header sections corresponding to spokes * sections for now only contain a visited=1 key/value pair * could be easily extended in the future to include more information about what user did in the spoke if needed * example config file snippet: [DatetimeSpoke] visited=1 * it seems sensible to write sections only for spokes that the user visited, not all spokes * all sub-classes of the Spoke class should be recorder if they are visited, including addons * Initial Setup will also need to record spoke visits as there might be another setup tool chained behind it (and GIS indeed runs after IS on RHEL7) * should we also report hubs the user has visited ? at least for now the number of hubs and their order are fixed Looking forward to your feedback! :)

10 28

random pool entropy starvation in initrd with parse-kickstart
by Brian C. Lane 26 Nov '15

26 Nov '15

Trying to write down some of the things I know so that I don't forget and so that maybe someone else can figure this out. I've been testing with a PXE setup using rawhide boot.iso's that I've created. I'm injecting the modified code into the initrd by adding ,/path/to/extra.img to the initrd PXE entry. This also works for adding the kickstart at / If parse-kickstart is run before the kernel initializes the nonblocking random pool it appears to starve the system and it takes anywhere from several minutes to forever for the pool to be initialized and for the boot to continue. There doesn't seem to be much of anything feeding the entropy pool in the initrd. https://github.com/rhinstaller/anaconda/pull/458 waits for some number of bits before continuing, printing what's available as it waits. When running parse-kickstart early the pool sits at 0 pretty much forever. When running it later it starts around 50, pool initialization seems to happen at around 300 (even though the code in the kernel random.c is checking for 128). It is worse with inst.ks=file, which will hang nearly forever. Moving it to run in the initqueue with wwoods' patch improves things, it eventually runs so that's an improvement. inst.ks=http will eventually run, but it may be minutes (I've seen as long as 5 in non-exhaustive timing tests). I tried reducing the random.py value from 2500 back to 32. This was not a quick fix, it still delays. I also tried skipping the initialization by setting a=None and that made no observable differece. This probably means that there is more to this than just the python 3.5 change. I tried adding qemu and qemu-net to the initrd with lorax, thinking that virtio-rng would magically start feeding entropy from the host. It didn't appear to help, but also doesn't hurt. Maybe rngd is needed? Not sure how well that would work with running in the initrd. I'm not sure where to go next with this, reducing/removing the random.py init and still having it get stuck would seem to indicate some other thing is involved, but david shea has straced it and it is getting stuck in the python read from /dev/urandom. Also, things boot normally if inst.ks isn't passed. pool initialization happens at about 14 seconds. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

3 6

proposal for splitting translation tests into a separate project
by David Shea 19 Nov '15

19 Nov '15

Sometimes we make a Fedora release in which translations crash anaconda, and that sucks, and I'd like us not to do that. I have the beginnings of an idea of how not to do that and I'd like some feedback. We have a handful of tests against translations in anaconda, but it's not just anaconda that's translated. Given that errors in translations in any library used by anaconda can crash anaconda, I feel that it's important to test the translations in all of the code we maintain to make sure that mistakes from translators aren't going to make anything blow up. The transifex/zanata model is nice in that the code repository isn't crudded up with constant translation commits, but its biggest pitfall is that translations, and mistakes in translations, can be changed right up until the moment we create a release tarball. For that reason I'd like the tests to be run both as part of the jenkins CI and just before a release is built. The input would be the source tarball: the output of make dist for anaconda, make archive for blivet, etc. This would not be as simple as moving tests/gettext/ into its own repo and adding a script or two. Most of the tests in tests/gettext/ test translatable strings rather than translated strings, and tests against translatable strings are mostly anaconda-specific. The tests I would like to move out of anaconda and run against every project are: - gettext/gettext_warnings.sh, which mostly catches busted format strings (including errors on our end where the string needs named parameters) - the translation portion of glade/check_markup.py (I could go either on this, since it should really only be anaconda that has markup strings, but I think it should at least be something that is run at package build time) - a new test in reaction to 1283599 in which the translator screwed up the Plural-Forms header in lt.po in blivet. Which leave these staying behind: - click.py, which ensures "clickable" anaconda info bars have something to click - contexts.py, which ensures that strings with keyboard accelerators have a translation context. Stuff from outside anaconda shouldn't be adding keyboard accelerators - gettext_potfiles.py, which ensures we keep POTFILES.in up to date. anaconda is the only one using autotools so the only one with a POTFILES.in - style_guide.py, which checks that we say "host name" instead of "hostname" and stuff like that. I dunno, maybe every project should get that treatment? Argue your case. Discussion question: should this stuff go in a for-real package in Fedora? The pros would be easier release-time testing (could be an automatic part of rc-release or similar), integration with make ci, and Chris wouldn't need to configure any new stuff in jenkins. Cons would be that there's another package in Fedora and that testing translations in make ci would be adding yet more things out of our control. As far as how all of this looks, I was thinking just a directory of checkers (maybe convert gettext_warnings.sh to python for consistency) and a script that runs them all. I suppose how the script finds the checkers depends on how real of a program we want it to be, whether it would need an argument to the directory or could just search via python imports.

4 9

RFC: Rewriting of Dogtail tests
by Alexander Todorov 17 Nov '15

17 Nov '15

Hello everyone, in the last several days I've made an almost working rewrite of the existing Dogtail tests. You can see my commits here: https://github.com/atodorov/anaconda/commits/gui_tests_rewrite or alternatively the gui_tests_rewrite branch. They are not very well organized, especially in the beginning. I will submit cleaner commits for a PR once everything is ironed out. Basically I've moved all .py files under the main tests/gui/ directory and updated run_gui_tests.sh a bit. I've simplified the test classes a bit so that nose can execute them directly. No need for the template.py file. VM dependency is removed, anaconda is executed directly from git using the --image option to point to the disk. Some of the inside/ test cases have been updated to reflect the fact we're no longer in a LiveCD. Some names have not been updated yet. Some things were temporarily disabled: - clicking the Help button causes yelp to become a zombie, bug referenced in commit - check_lang_locale_views iterates over some gui elements and this causes NotImplementedError in AT-SPI. I suspect the API has changed slightly but didn't investigate. I wanted to get things working before that. If you want to execute this locally you will need 1) Apply this to your local blivet installation: https://github.com/rhinstaller/blivet/pull/267 otherwise anaconda won't see the disk images. 2) Install Dogtail for Python3. I'm building from source: https://vhumpa.fedorapeople.org/dogtail/beta/dogtail3-0.9.1-0.3.beta3.src.r… You need to make sure accessibility is enabled (try the sniff3 tool) before continuing further. 3) Checkout the gui_tests_rewrite branch; build anaconda and (as root): # setenforce 0 # export top_srcdir=`pwd` # cd tests/gui/ # ./run_gui_tests.sh ^^^ I'm running this from inside a desktop session. It is possible to run over SSH but I'm still not sure how to check/configure the environment from the shell. 4) Anaconda will start and you can watch Dogtail drive the installation. Don't touch it or it may fail if you close some dialogs it is looking for. Output is here: http://fpaste.org/291469/14477766/ Note: I could be missing some test results/log files but that should be easy to fix. Warning: I do have a debugging print in runTest, grep for "*****". This is because after the first 2 test cases have been executed anaconda is started without any disk images: ***** args ['/home/atodorov/anaconda/anaconda', '-G'] <class 'tests.gui.test_reclaim.transplant_class.<locals>.C'> I have no idea what that is but a quick search for "nose transplat_class.<locals>.C" found this: https://github.com/nose-devs/nose/issues/928 which in turn links to a Python 3.5 bug and 3.5 is what I have on Rawhide right now. I should give it a try on Fedora 23 with Python 3.4 to see if that makes any difference. Please comment on this, there's still quite a few things to be done before ready. -- Alex

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel November 2015