Anaconda-devel May 2016

anaconda-devel@lists.stg.fedoraproject.org

12 participants
4 discussions

anaconda-patches mailing list
by Samantha N. Bueno 26 May '16

26 May '16

I'd like to see what are everyone's thoughts on decommissioning anaconda-patches list. Now that we've moved to GitHub, it's pretty much obsolete, and I think decommissioning it could be beneficial: (a) (Way) less email overall. (b) The GitHub email script that we have was originally created with the intent of preserving the posted patches + discussions forever in history, but the patches are not actually included in any emails. Additionally, unless someone makes an in-line comment in the patch, there usually is no context provided in responses. So, the emails don't contain a lot of value. (c) It's a good way to force all the stragglers (e.g. myself) to migrate their workflow to GitHub and have everyone working the same way. (d) As a benefit of (c), less confusion for new contributors, concerning how to post a patch, etc. I know we can disassociate the webhook email forwarder from GitHub pretty easily. Concerning the list itself though, if there's a way to effectively "close it for business" but leave its contents forever available for perusal, I think that might be ideal. Anyway, thoughts? Samantha

9 17

How to support disabling of activation of first kickstart network command?
by Radek Vykydal 25 May '16

25 May '16

Hi, For compatibility with RHEL 6, and kickstarts out there, we always activate the device of the first network command in installer environment (we are assuming --activate option). The problem is that there is no way to turn this default off. There are BZs appearing that hit this limitation [2]. The use case is: - configure a device for installation in dracut stage (to fetch kickstart, or perhaps even the payload) - via boot options - use another configuration of the device for target system - via kickstart Activating the target system configuration in installer (after switchroot) can result for example in unreachable source, disconnected/stalled nfs mount of installer image, ... I can see three options to support such use cases: 1) A workaround: use dummy first network command with non-existing device. Anaconda will just ignore it: network --device=NONE network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4 Or in case hostname is configured, use this as first network command network --device=NONE network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4 ... well, it is just an ugly workaround 2) Change the behaviour - treat the first network command same as other network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4 ... I am afraid we can't afford such a change with respect to users already relying on current behaviour.IIRC 3) New network kickstart command option --donotactivate with lower priority than --activate. Which means it would effectively apply only to the first network command, for other commands it is the default. network --device=ens3 --ipv6=2001::1/64 --gateway=2001::2 --noipv4 --donotactivate ... does not seem very elegant In my opinion, for RHEL 7 (and maybe even for master) we should go with 3) What do you think? Radek [1] or reactivate it with kickstart configuration in case it has been already activated in dracut [2] https://bugzilla.redhat.com/show_bug.cgi?id=1338631 https://bugzilla.redhat.com/show_bug.cgi?id=1277975

3 6

UI decisions based on payload
by Colin Walters 13 May '16

13 May '16

I wanted to start a quick architecture discussion here based on https://github.com/projectatomic/fedora-productimg-atomic/pull/3 I'd like down the line if more decisions like this were based on the *content* and not the productimg, because it's more generic. It'd be quite possible and reasonable for someone to regenerate the ostree commit with documentation downstream. Similarly, people composing Workstation systems are probably going to include docs. In a network install scenario, I know this gets a bit more complex, as we would need to fetch some metadata (which could be the ostree commit object) to determine this. But in the case of an Atomic Host ISO where we embed the ostree content, there shouldn't be any network bootstrapping issues; we have the content in the ISO. That way things would similarly Just Work for a Workstation case In order to make this work, we'd need to teach rpm-ostree to write out well-known metadata in the ostree commit, and change Anaconda to look for it.

2 1

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel May 2016