Anaconda-devel December 2015

anaconda-devel@lists.stg.fedoraproject.org

13 participants
10 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

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

lorax - selinux limitation
by Dominique Martinet 24 Dec '15

24 Dec '15

Hi, in el7, in /usr/lib/python2.7/site-packages/pylorax/__init__.py we have this comment/code: # is selinux disabled? # With selinux in enforcing mode the rpcbind package required for # dracut nfs module, which is in turn required by anaconda module, # will not get installed, because it's preinstall scriptlet fails, # resulting in an incomplete initial ramdisk image. # The reason is that the scriptlet runs tools from the shadow-utils # package in chroot, particularly groupadd and useradd to add the # required rpc group and rpc user. This operation fails, because # the selinux context on files in the chroot, that the shadow-utils # tools need to access (/etc/group, /etc/passwd, /etc/shadow etc.), # is wrong and selinux therefore disallows access to these files. logger.info("checking the selinux mode") if selinux.is_selinux_enabled() and selinux.security_getenforce(): logger.critical("selinux must be disabled or in Permissive mode") sys.exit(1) I've just generated new images on a centos7.1 box with selinux enabled and it didn't seem to run into any selinux-related trouble after disabling this check - in particular, /etc/passwd in the LiveOS image does contain rpcuser and there wasn't any obvious error message in the whole lorax process. Would it be possible to remove this now? (do you want me to send a trivial patch that just removes this bunch of lines so my name is on it for future complains?) -- Dominique Martinet

3 6

sudo -i, prompt missing hostname
by Chris Murphy 10 Dec '15

10 Dec '15

System with root user password set in installer: [chris@f23m ~]$ sudo -i [root@f23m ~]# rpm -q sudo sudo-1.8.15-1.fc23.x86_64 [root@f23m ~]# echo $PS1 [\u@\h \W]\$ System with root user not set in installer [chris@f23a ~]$ sudo -i [sudo] password for chris: -bash-4.3# rpm -q sudo sudo-1.8.15-1.fc23.x86_64 -bash-4.3# echo $PS1 \s-\v\$ Of course the problem is without creating root user, there is no /root/.bashrc or /root/.bash_profile. Is it sane to always create those files, even if root user password isn't set? That way sudo -i still results in a descriptive prompt? If it's sane, I'll file an RFE. Thanks, -- Chris Murphy

1 0

Repackage lorax templates?
by Brian C. Lane 10 Dec '15

10 Dec '15

I think this was something Will and I had discussed at one point: Split the share/*tmpl file and the bootloader configs out into a separate package like lorax-generic-templates. This would make it clearer (along with some docs) that lorax can be used to create customized boot isos. eg. include or exclude specific addons, dependent packages, custom boot menus, etc. This would fit in with making a docker kickstart addon package that some variants would only be included in some variants, or modular payload support, etc. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

2 1

Modular payload support?
by Brian C. Lane 07 Dec '15

07 Dec '15

I had a half-baked idea this morning. I wonder if it would be worthwhile to make the payloads more modular so that you could put together an anaconda image that only supported deb packages for exampel. Right now any new payload needs to be added to pyanaconda/anaconda.payload along with the logic for selecting it. Instead we could change payloads to a registration model, like installclasses, and then call their probe() functions (with some kind of weighting) and let them decide which one to use. Ignoring the complications from different UI support :) this would allow new methods to be dropped in by 3rd parties (like addons) without having to modify the core anaconda code. It would also be possible to split out the individual payloads into subpackages, allowing for simpler installer images. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

3 3

Looking at the payload from an addon
by Pat Riehecky 07 Dec '15

07 Dec '15

I'm working on an addon where I'd like to do a bit more introspection on the payload within the addon itself. So I started working on the kickstart aspect and ran into a bit of confusion. For what I'm doing I need to act a bit differently if the payload is yum vs dnf vs ostree. However, I don't see a way for me to look at the payload object from within the kickstart functions. Did I miss where I can get to it? Any suggestions? Pat -- Pat Riehecky Scientific Linux developer Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

2 4

Should we include docker support by default?
by Brian C. Lane 04 Dec '15

04 Dec '15

I've been doing some experiments for bz#1283701, supporting running docker at install time to pull down images without rebooting into the system first. At first I thought it would be much harder than it is. I've added docker and some support libraries to lorax, they only added about 12M and that's before I've even looked at trying to trim them down at all. I have an experimental %post --nochroot that starts up docker, points to the LVM thin pool (setup by kickstart, not docker-storage-setup), and pulls down a couple simple images. It writes the config to the target system and kills off docker. The only slightly odd part is bind mounting /var/lib/docker to /mnt/sysimage/var/lib/docker so that everything it writes ends up on the target system. I propose turning the %post hack into some kickstart commands for setting up the storage, pulling images, and doing whatever other normal setup things are needed. What do you think? Is this worth the extra 12M (or so) to add this? -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

4 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel December 2015