Anaconda-devel January 2016

anaconda-devel@lists.stg.fedoraproject.org

9 participants
8 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

Anaconda Docker addon review needed
by Brian C. Lane 12 Feb '16

12 Feb '16

Here's a pile of code that needs to be reviewed. I totaly failed to figure out how to do a PR against a blank repo so I just pushed it. https://github.com/rhinstaller/docker-anaconda-addon I'll also need a package review once I create that. The spec, etc. can be found here: https://bcl.fedorapeople.org/docker-anaconda-addon/ Thanks! -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

2 7

releasing pykickstart-3
by Chris Lumens 28 Jan '16

28 Jan '16

Lately, I've been working on a new major version of pykickstart that will be incompatible with the current version. This incompatibility is because I've moved to the python argparse module from the deprecated optparse. The boring details are here: https://github.com/rhinstaller/pykickstart/blob/master/docs/2to3 Anyway, pykickstart has a rich tradition of not screwing users over. I'd like to continue that when I release major version 3. However I don't really know how to go about doing it while still leaving pykickstart-2 around for people to take their time moving from. I guess the typical way is to create a new package that can be installed alongside the old one, right? I kind of hate that. Are there other options? - Chris

3 5

Anaconda Thread timeout
by Pat Riehecky 26 Jan '16

26 Jan '16

Is there a clean way to set a maximum runtime for an anaconda thread? Pat -- Pat Riehecky Scientific Linux developer Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

3 3

Unit Testing anaconda addons?
by Pat Riehecky 20 Jan '16

20 Jan '16

I've been building up some tests for my addon, but I've run into an interesting problem. How do I interact with the ThreadMgr within my tests? It seems to be None..... Any ideas? Pat -- Pat Riehecky Scientific Linux developer Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

2 3

Switch livemedia-creator to qemu instead of virt-install
by Brian C. Lane 12 Jan '16

12 Jan '16

I'm considering switching lmc to use qemu directly instead of virt-install+libvirtd. Currently lmc can use virt-install to create the full range of supported images. But this doesn't work when running inside mock, which is used by Fedora releng's koji system. It also supports the --no-virt mode which runs anaconda directly in the same environment as lmc. The benefit is less things to setup and it works inside mock. But the drawback is that it uses device-mapper for installing to a partitioned disk image, and device-mapper doesn't work inside mock. So when running in mock you can only create a live iso or a filesystem image, not anything that needs a partitioned disk. I've been doing some experimenting and it ends up that qemu works inside mock. Switching to qemu (with optional auto-detection of when it could use qemu-kvm to speed things up) would simplify the code and allow it to create all the image types no matter where it is run from. It is also possible (I haven't tried this yet) that it could be used to create cross-arch images as well, since qemu has a wide range of supported arches. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

3 4

livemedia-creator --live-iso deliverables
by Dennis Gilmore 08 Jan '16

08 Jan '16

Hi, Today I was running through runs of livemedia-creator in mock to figure out what exactly we need to get koji to run in order to produce the liveiso's I got things running and was able to produce a live iso. aside from things like the iso being ~1G bigger than what we get from livecd-creator I had one big surprise. The surprise was the output that we got. In Release engineering we want the tooling to make the artifact as we are going to ship it. This means that someone running the tool at home can make the same thing as what we make. I was expecting for output something along the lines of Fedora-Live- Workstation-x86_64-rawhide-20151215.iso which is what we get from livecd- creator. Instead of just an iso what I got was a tree EFI EFI/BOOT EFI/BOOT/BOOTX64.EFI EFI/BOOT/MokManager.efi EFI/BOOT/grubx64.efi EFI/BOOT/grub.cfg EFI/BOOT/fonts EFI/BOOT/fonts/unicode.pf2 images images/pxeboot images/pxeboot/vmlinuz images/pxeboot/initrd.img images/install.img images/efiboot.img images/macboot.img images/product.img images/boot.iso isolinux isolinux/vmlinuz isolinux/initrd.img isolinux/isolinux.bin isolinux/vesamenu.c32 isolinux/ldlinux.c32 isolinux/libcom32.c32 isolinux/libutil.c32 isolinux/isolinux.cfg isolinux/grub.conf isolinux/boot.msg isolinux/splash.png isolinux/memtest LiveOS LiveOS/squashfs.img where the only thing that we will ship is images/boot.iso but we will have to do manipulation of the tree to keep what we want and name it correctly and discard all the extra bits. this means that every use that makes livecds will need to write tooling to extract the boot.iso, rename it and discard the extra bits. given http://dl.fedoraproject.org/pub/fedora/linux/releases/23/Live/x86_64/ as an example of how we ship live media it is not a great thing to have to do. I strongly feel that a small piece of additional code in livemedia-creator to correctly name the iso given that there is a --image-name flag is reasonable and will save every person that makes livemedia from having to rewrite basically the same function, or us just writing a wrapper around livemedia- creator to do so. I am happy to write the code but want to make sure that it will be welcome before I go off and do so. This is a feature we are trying to get into the compose tools and process for Fedora 24 so that we can get rid of livecd- creator and appliance-creator once and for all Regards Dennis

5 14

Anaconda spoke workflow
by Pat Riehecky 04 Jan '16

04 Jan '16

I'm focusing a bit on my GUI spoke workflow and ran into an odd snag. The spoke is optional (@property mandatory = False and @property completed = True). It only makes sense to manipulate the spoke's data after the network has come online. If nothing is set on the spoke, this is fine and no actions are performed. My initial thoughts were to make @property ready return the value of pyanaconda.nm.nm_is_connected(). However, if the network is never connected then spoke is never ready and therefore install can never proceed. Are there any suggestions for how I can get what I'm looking for where the user can't use the spoke without the network but the spoke doesn't block the install? anaconda-19.31.123 Pat -- Pat Riehecky Scientific Linux developer Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

5 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel January 2016