Anaconda-devel February 2016

anaconda-devel@lists.stg.fedoraproject.org

16 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 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

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

Require glibc-all-langpacks in f24 up
by Dennis Gilmore 27 Feb '16

27 Feb '16

Hi all, The short summary is that all install environments using anaconda in f24 and up are broken, the reason is that there is no locale data. I think that the answer is to have anaconda add a Requires on glibc-all-langpacks to ensure that all locales are present. Dennis

1 0

update on Wayland and the installer
by David Shea 26 Feb '16

26 Feb '16

Summary: don't do anything. Wayland by default is a goal for F24 Workstation (https://fedoraproject.org/wiki/Changes/WaylandByDefault) and if all goes right, then the Workstation live installer will be running on Wayland. We don't need to do anything for that to happen. We should keep an eye out for anything that might be going weird with anaconda running on Wayland (any of the places where we use Gdk functions directly deserve a look), but that's it. For non-live media, the consensus is to just leave things the way they are for F24. X is not going away, and X is still necessary as a fallback for certain cases, so for boot.iso/netinst just keep using X. We can give this a closer look post-F24. If we do decide to switch to Wayland post-F24, that would mean at the least swapping out metacity for gnome-shell running in kiosk mode (like how gnome-initial-setup runs).

4 3

Move Lorax templates into templates.d and a subpackage
by Brian C. Lane 12 Feb '16

12 Feb '16

https://github.com/rhinstaller/lorax/pull/86 is a patchset to, hopefully, make it easier for products to customize the boot.iso they want to create. It moves the templates from /usr/share/lorax/ into /usr/share/lorax/templates.d/99-generic/ so that other templates can be installed without conflict. It picks the first template directory in templates.d (sorted alphabetically) or falls back to the old /usr/share/lorax/ path. --sharedir overrides this and points it to the template directory to use. This would allow products, like server, to ship lorax templates as part of the productimg package and use them during the build process. Note that the lorax.rst docs haven't been updated yet, and I just noticed that I need to add a Requires: lorax-templates to the lorax package to make sure it pulls in something. Any thoughts on this would be appreciated, either here or in the PR. Thanks, -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

2 2

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

error setting up base repository
by CLOSE Dave 04 Feb '16

04 Feb '16

The subject message sometimes appears on the installation source entry from anaconda. But I have never been able to find a good way to learn just what the error is. Sure, sometimes it's obvious: the URL is wrong. But other times everything seems to be correct but still the error persists. I'm looking for a checklist of possible causes or a log entry that corresponds to the problem. In my present effort, I'm attempting to use a local mirror of the fedora-updates repository (in addition to local mirrors of the fedora and other repositories). I believe the mirror is correct and complete. The machine being installed has no trouble accessing the repo from an F2 shell while anaconda is running. Looking through the anaconda logs, I find lots of references to the updates repository but no errors. What can cause this error message? And how do I find out what caused it in this instance? -- Dave Close

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel February 2016