Anaconda-devel March 2016

anaconda-devel@lists.stg.fedoraproject.org

14 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

Potential deprecation in RHEL 7.3 ADDON API
by Jiří Konečný 18 Apr '16

18 Apr '16

I have RFE which required to add payload class to addons so I created this PR: https://github.com/rhinstaller/anaconda/pull/571 This PR will cause that all existing addons to get deprecation warning message. This includes our OSCAP and KDUMP addons. The change is really small. You only need to change two lines of code. I'm going to create PR for our addons when this PR receive ACK. This change happens on master and it will be also in RHEL 7.3 . I want to give you notification about this change before it happens by this mail. If I missed something or you don't want this change please write comments to PR or reply to this mail. Thank you, Jirka K.

5 9

Proposal for testing anaconda updates
by Adam Williamson 01 Apr '16

01 Apr '16

Hey folks! Thought the list might be interested in this, so I'm sending it along: https://fedorahosted.org/rel-eng/ticket/6383 it's an idea I had for solving the problem of testing anaconda updates, which we currently just don't have a good way to do. I would like to see a system which would a) let us test them automatically with openQA, and b) provide a compose for people to run manual tests with. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 1

Announce: blivet-2.0.0
by David Lehman 29 Mar '16

29 Mar '16

Hi everyone, I would like to announce the release of blivet-2.0.0[1]. See the release notes[2] for information about all of the changes in this version and the documentation[3] for the public API specification. Some of the larger changes: - full PEP8 compliance - thread-safety - added support for creating LVM RAID volumes - added support for resizing LUKS encrypted block devices - use libbytesize[4] as the backend for blivet's Size class - device tree updates based on uevents (disabled by default) - dropped support for python2 For now there is a blivet-2.0.0 build in my copr[5] for anyone who wants to check it out. I also want to give a heads-up that I plan to build blivet-2.0.1 in rawhide next week, which means switching anaconda to use it at that time. Thanks, David [1] https://github.com/rhinstaller/blivet/releases/tag/blivet-2.0.0 [2] https://github.com/rhinstaller/blivet/blob/2.0-release/release_note s.rst [3] http://rhinstaller.github.io/blivet/docs/api.html [4] https://github.com/rhinstaller/libbytesize [5] https://copr.fedorainfracloud.org/coprs/dlehman/blivet/

2 1

Network Dracut/Anaconda priority specification
by Jiří Konečný 16 Mar '16

16 Mar '16

Hi all, please look on this PR[0] and comment if you think I'm wrong. I want to use the diagram there as base for future specification to the anaconda docs. Also I want to know if I'm not changing the behavior too much for RHEL7. It's missing many parts but I found there are many blind spots for me now so I want to remove them and document the Dracut/Anaconda network stuff. [0]: https://github.com/rhinstaller/anaconda/pull/548 Jirka

2 1

Anaconda uses too many addresses
by CLOSE Dave 12 Mar '16

12 Mar '16

The environment here is Fedora 23. One machine acts as DHCP server for the others (normal, I know). A small portion of each subnet is reserved for dynamic assignment, devices without reserved addresses. Lately, when I run PXE on a new machine, I find that three or more of those addresses are reserved for Anaconda! Even though all the requests originate from the same MAC address, the DHCP server gives each request a unique response. As the address leases take time to expire, I quickly run out of available addresses. Much more quickly than I should. I don't recall this happening when doing the same operations on a Fedora 20 base, both DHCP server and PXE installations. I realize this may be a DHCP issue. But to cover all bases, I wonder if there is anything Anaconda is doing that could exacerbate this problem. -- Dave Close

3 3

anaconda design mockups
by Garrett LeSage 10 Mar '16

10 Mar '16

Hi all, It was great to meet many of you while visiting the Brno office earlier this month! Also, hi to all of you also that I didn't see this month, including some of you I already know from a long, long time ago. (: For those who don't know me, short bio (feel free to skip): I'm a designer in the free software world (since 1996 — time flies!), and I like to work with others to help improve software interaction and aesthetics. I have a strong computer background (CS in Uni; local computer expert well before that) and have done a bunch of stuff in the community for the past few decades. You most likely know/use a few projects I started and have been involved with and might even use a photograph I snapped as wallpaper too… but anyway, back to the real subject… Here's a link to the mockup I have been working on: https://people.redhat.com/glesage/project/anaconda/anaconda-redesign-2016-g… (Most browsers will force you to click to zoom. Alternatively, you can wget/curl/save-as the file and open it in an image viewer and pan around at 1:1 for better viewing.) I refined it a few times with input from several people, including Máirín. (Her comments are in the mockup in a pinkish-purple color, as we're having a discussion in the mockup itself, to try to figure out how to possibly best do certain things.) The main purpose behind the mockup is to optimize Anaconda for both the Workstation and Server "flavors" of Fedora (and RHEL and CentOS). The mockup itself is focusing mainly on Workstation first, so not everything you see will apply to Server, and some server-specific things are deliberately omitted from Workstation. (The already-ongoing modularization efforts should really help with the differentiation between Workstation and Server too, of course.) Naturally, this is just the start — the mockups are not meant to be concrete nor are they final — and they're missing a lot of details (mainly in screens not pictured yet and also in implied interactions based on the widgets). I'm looking forward to working with you all so that we can solidify the design and get the details defined together. So, what do you think? BTW: Source for the file is at https://github.com/fedoradesign/anaconda/tree/master/Visual%20Redesign%2020… in SVG (made with Inkscape). Warning: The repo is a bit messy, as it's a WIP design exploration ground. 😉 Cheers, Garrett

12 26

pykickstart-3 copr
by Chris Lumens 07 Mar '16

07 Mar '16

I've tagged and pushed the 3.0 version of pykickstart to github. I've also made a copr available with a build in it: https://copr.fedorainfracloud.org/coprs/clumens/pykickstart-3/ I'll be doing this periodically as I continue working on this branch. I'm targeting merging it into Fedora proper after F24 is done. I think that should give people enough time to adapt their code to the new ways of doing things. - Chris

2 2

Blocker status of RHBZ #1033778 (shrinking unknown volumes)
by Adam Williamson 03 Mar '16

03 Mar '16

Hi folks! So as promised on IRC here's a mail to discuss this issue. https://bugzilla.redhat.com/show_bug.cgi?id=1033778 is proposed as a release blocker. As I understand it, dlehman is strongly of the opinion that it shouldn't be accepted, on technical grounds. However, it does constitute a fairly clear violation of the release criteria. The bug - as I understand it - is that a particular type of partition ("Apple Core Storage" volumes, whatever those are) appears as "Unknown" in anaconda, and the guided install workflow (the "Reclaim Space" screen) allows you to try and resize it. If you do this, it fails to work at all and causes complete loss of all data on the partition. The Final release criteria state: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation." with a footnote: "This means that if the installer offers mechanisms for resizing storage volumes, then it must run the appropriate resizing tool with the appropriate parameters for the resize the user chooses. The reason it's worded this way is we specifically don't want to cover cases where the requested resize operation then fails for some reason - dirtily unmounted or over-fragmented partition, for instance. We only want to cover the case that the installer's resize code itself is badly broken." It seems pretty inarguable that as the criteria currently stand, this bug violates them, and thus it should be a Final release blocker. However, we delayed the decision at this week's blocker review meeting since we were aware you folks might want this not to be a blocker. For clarity, if it were to be accepted as a blocker, this would not mean that anaconda would be required to resize such partitions successfully, nor does it necessarily imply that anaconda must be able to *recognize* such partitions. So far as the blocker process is concerned it would be a sufficient resolution if *either* anaconda attempted to resize such partitions 'appropriately' (I'm not sure if that is even possible) *or* refused to attempt to resize them. The criteria do not, I think, place any effective restrictions on exactly *how* the latter resolution could be effected. So, I guess the question is: do we think the criteria should stand as written but this bug be rejected, and if so on what grounds? Do we think the criteria should be adjusted to reflect some kind of technical restriction? Or do we in fact think the bug should be accepted (and presumably the 'fix' should be to disallow resizing of this kind of partition somehow)? I asked on IRC whether it would be possible to disallow resizing of 'unknown' partitions. As I understand it the problem with this is it's difficult or impossible to distinguish between an empty partition and one that contains an unknown filesystem (and, presumably, one that is not empty, but contains garbage). I wonder, though, is that actually a problem? Do we need to allow 'resizing' of such partitions, or can we simply say that you should delete and recreate such partitions, and we will only allow the operation we call 'resizing' for partitions we definitely know the filesystem of and that we can safely resize that filesystem? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 10

Using livemedia-creator with RHEL7
by Lukas Zapletal 03 Mar '16

03 Mar '16

Hello, I build live images of RHEL/CentOS 7 with traditional tools [1] and I am wondering if I could use Lorax utilities to do the same. I understand that RHEL7 has dated Anaconda and Yum, but maybe I do things wrong: [lzap@lzapx foreman-discovery-image]$ sudo livemedia-creator --make-iso --iso /mnt/data/isos/CentOS-7-x86_64-Everything-1511.iso --ks fdi-image.ks 2016-03-01 13:42:20,604: disk_size = 1026MiB 2016-03-01 13:42:20,605: disk_img = /var/tmp/disk7vld5vjj.img 2016-03-01 13:42:20,605: install_log = /home/lzap/work/foreman-discovery-image/virt-install.log 2016-03-01 13:42:20,638: Running virt-install. 2016-03-01 13:42:21,532: Processing logs from ('127.0.0.1', 53448) ... 2016-03-01 13:42:51,827: Installation error detected. See logfile. 2016-03-01 13:42:51,828: Shutting down LiveOS-0b814a3b-331d-4c21-9560-dd8f291557be Domain LiveOS-0b814a3b-331d-4c21-9560-dd8f291557be destroyed Domain LiveOS-0b814a3b-331d-4c21-9560-dd8f291557be has been undefined 2016-03-01 13:42:52,093: Shutting down log processing 2016-03-01 13:42:52,093: unmounting the iso 2016-03-01 13:42:52,125: Install failed: virt_install failed on line: 12:42:46,593 CRIT anaconda: Traceback (most recent call last):#012#012 File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/tui/simpleline/base.py", line 348, in _mainloop#012 prompt = last_screen.prompt(self._screens[-1][1])#012#012 File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/tui/hubs/summary.py", line 85, in prompt#012 raise CmdlineError(errtxt)#012#012CmdlineError: The following mandatory spokes are not completed:#012Installation Destination 2016-03-01 13:42:52,126: Removing bad disk image 2016-03-01 13:42:52,126: ERROR: Image creation failed: virt_install failed on line: 12:42:46,593 CRIT anaconda: Traceback (most recent call last):#012#012 File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/tui/simpleline/base.py", line 348, in _mainloop#012 prompt = last_screen.prompt(self._screens[-1][1])#012#012 File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/tui/hubs/summary.py", line 85, in prompt#012 raise CmdlineError(errtxt)#012#012CmdlineError: The following mandatory spokes are not completed:#012Installation Destination [lzap@lzapx foreman-discovery-image]$ cat fdi-image.ks | paste http://sprunge.us/dQWA If that's not possible, are there plans to backport things into RHEL7? Thanks for advice! [1] https://github.com/theforeman/foreman-discovery-image -- Later, Lukas #lzap Zapletal

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel March 2016