Anaconda-devel February 2014

anaconda-devel@lists.stg.fedoraproject.org

12 participants
5 discussions

Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Adam Williamson 27 Feb '14

27 Feb '14

On Fri, 2014-02-21 at 16:38 -0500, John.Florian(a)dart.biz wrote: > > With the best of intentions, we'd gone from a reluctant exception to the > > 'no choice' design to a dropdown which included two very different > > complex choices: LVM and btrfs. So now the installer path which was > > originally supposed to be minimal-choice, very robust and testable and > > fixable, had become rather a lot more complex. > > Everything should be made as simple as possible, but not simpler. I don't think that precept applies very well to this area. The problem is that there are - and this is probably *literal*, not a rhetorical flourish - millions of Special Little Use Cases like yours (the one below, snipped for brevity) out there. *You* want it to be easy to skip /home. *She* wants it to be easy to resize a Slackware install. *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very, very clear that we just cannot undertake to support them all and guarantee that they are all going to work in a release. It's just _too much work_. Everyone agrees that it would be nice if we could, but then everyone agrees that it'd be nice if I had a solid gold toilet. Some nice things just don't happen. We do not have the resources to be in the business of writing the world's biggest disk configuration tool and guaranteeing that it'll never go wrong, which isn't *quite* what we're currently trying to do, but it's not far from it. It's worth trying some other installers out, just to reset your expectations. Have you seen the level of flexibility you get from Ubuntu's interactive installer? Windows'? OS X's? > I > appreciate your QA angle here. Every condition in a code path leads to > exponential growth in testing. And development. This isn't just a QA problem. We do not have the development resources to commit to all this stuff working reliably every six months. > However, when I have my admin hat on, I > want flexibility. I love LVM for that reason. However, if I'm setting up > simple VMs whose backend storage resides in a LV, I have no need or desire > for LVM within the VM. Does it hurt you to get it, though? I do my VM installs with LVs. I don't really need them. But nothing explodes, and two hours later I forget all about it. In the end it's just bits. As long as the bits are where they need to be when things need to read them, who *gives* a monkey's tail? I did recognize that it would be tough sledding to get back to zero choice, and if you ask me to crystal ball it, we might have to wind up back at 'plain partitions or LVM'. But that's still a substantial improvement on where we are right now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 4

Anaconda and python-coverage
by Alexander Todorov 25 Feb '14

25 Feb '14

Hi guys, I'm experimenting with python-coverage and have an updates.img against a RHEL 7 tree which successfully starts, stops and saves the resulting data from coverage. My issue is that when doing a coverage report I don't see much info for anaconda and pyanaconda. The only line for anaconda is about /usr/sbin/anaconda. The rest are blivet, pykickstart, meh, dbus and other python modules but not pyanaconda. Any ideas ? Notice: There are some known issues with coverage: http://nedbatchelder.com/code/coverage/trouble.html but the version of anaconda I'm using (anaconda-19.31.51) doesn't seem to suffer from them. -- Alex

3 10

Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Chris Murphy 24 Feb '14

24 Feb '14

On Feb 21, 2014, at 2:38 PM, John.Florian(a)dart.biz wrote: > That makes a lot of sense, but I'd like to add that when doing custom partitioning, you can easily spend the bulk of your actual interaction time getting the partitioning customized exactly the way you want and when anaconda crashes, What you're essentially suggesting is the necessary trade off between stability and features isn't being balanced, in your experience. I'd agree with that assessment. I've done hundreds of Windows installs and thousands of OS X installs and those installers never crash. Ever. Seriously never. You can throw the most bizarre crap at them, even a disk with 42 partitions of just linux and BSD and they don't crash. And what interaction time? It's point and install. There's nothing to interact with because there are no options. > However, when I have my admin hat on, I want flexibility. I don't find that a compelling argument for many reasons, not least of which is the tens of thousands of OS X and Windows admins who get few install time layout choices, and they seem quite content. And they don't even have a kickstart equivalent, so I think it's fair to say flexibility is served by kickstart. > However, if I'm setting up simple VMs whose backend storage resides in a LV, I have no need or desire for LVM within the VM. It only makes more work if I have to do an in place resize later on. Having LVM on those host makes that resizing oh so much simpler though, especially if additional drives are required. > > I feel much the same about the /home partitioning and wish there was an checkbox in anaconda for that. Having a separate /home partition is good practice, but I never use the feature because mine is on NFS, so it makes for lots of click work to get the auto layout, then remove the home. (I did learn accidentally with btrfs I can just ignore it and I've not lost any space on /.) > So yes, simplicity is good, unless it makes everything else harder later. Elsewhere the idea is that the OS installer actually just installs the OS successfully. After that comes such customizations that we are putting into the installer that really don't need to be in the installer. Post-install if I decide I want /home on NFS, if I want encrypted /home, if I want to buy another drive and put /home on raid1, what do I use? Not Anaconda, it's an install time specific tool. The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. Chris Murphy

4 4

Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Adam Williamson 24 Feb '14

24 Feb '14

On Fri, 2014-02-21 at 17:08 +0100, Phil Knirsch wrote: > Installer is still a hot topic, but thats nothing we could resolve > during our meeting and which might have to be brought up with FESCO again. So, as cmurf has been trying to point out on desktop@ , we (QA) have some concerns in this area too, and I know the installer team is open to the idea of at least simplifying the non-custom partitioning path to some extent. This is an extremely complex topic area, though, and it may be tricky to get the right things done if multiple teams are considering it in different contexts in different meetings. It would probably be a Very Good Idea to get everyone with an interest - at least anaconda team, the product WGs (except possibly Cloud, depending on whether they intend to use anaconda in their deliverables at all), base WG, and fesco - together in some way to talk about it. devconf would've been great but it already happened. Flock would be great but it's too late. Should we try to set up some kind of special meeting / list / etherpad / wikipage / *something* where we can all talk it over? To give a bit of background and detail in QA's interest: First, to ensure everyone actually knows what we're talking about, we tend to talk about two major partitioning 'paths' in anaconda: 'guided' and 'custom'. 'custom' may also be referred to as 'manual'. In both newUI and oldUI, 'guided' is simply what you get if you don't pick custom partitioning, when you are given the opportunity to do so. In oldUI, you had the screen which gave you about five choices of different partitioning 'approaches' (reformat the entire disk(s), reformat only the Linux partitions, resize existing partitions to create free space, just install into free space, maybe one or two others I forgot). In newUI there's a different workflow after you pick target disks on the Installation Destination spoke which, broadly, accomplishes the same options in a rather different way. Broadly, QA is interested in doing something similar to what desktop wants to do, for slightly different reasons. Historically, QA and anaconda more or less agreed on an approach whereby the 'guided' partitioning path would be expected to work extremely reliably: QA would undertake to test every (well, nearly every) route through that path regularly and proactively, and anaconda would undertake to fix the bugs. Custom partitioning was much more of a 'bonus' thing: if it worked, great. QA would test it as much as we had time for, and anaconda would fix as many bugs as they could after fixing higher priority stuff. I went back and looked at the history, and in the earlier days of Fedora, the guided path was consciously designed to be very 'choice free'. Later in the 'oldUI' days, the path to more complexity in the 'guided' path was opened up by a sort of hack. Some people did not want LVM (after it was made default waaaaay back in FC3 or something), and eventually this demand became so persistent that it was decided to stick a checkbox in the 'guided' partitioning path which let you get a plain ext(3/4) layout instead of an LVM layout. This was always a kind of ugly compromise, it wasn't intended to be a design decision. It was manageable, because a plain ext3/4 layout is a fairly simple thing that isn't likely to break much. This context was kind of lost in the newUI re-design, and the 'I don't want LVM' checkbox kind of got a promotion. It's not a very good UI, and the point of the newUI stuff was to make the UI better, so instead of this 'special' checkbox, newUI used a dropdown menu - and because we were all ra-ra for btrfs at the time and expecting it to be the default Real Soon Now, and we thought we should make it easy for people to test the thing that was soon going to be the default, it got btrfs added. So in F18 we had a dropdown with "LVM", "ext4" and "btrfs" choices (IIRC). With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. By F20 we'd really kind of lost track of the initial intent, so no-one (including QA) really worried much about adding LVM thinp to the drop-down - it's a drop-down! it's for choices! - and now, we've got *four* major choices on the path that was originally supposed to be very dependable and choice-free and testable and maintainable, and of course we wound up shipping one of them entirely broken out of the box. QA and anaconda have already discussed this and, I think, we came to a tentative agreement that we could look at at least reducing the level of choice in 'non-custom' partitioning, and remembering the original intent we had (which I think both QA and anaconda teams quite like). It may be difficult to entirely drop the selection, but it seems at least reasonable to go back to only having one 'plain partition' choice and one 'LVM' choice (whether it's 'regular' LVM or thinp LVM), and relegating other choices to the 'custom' path. QA's angle on this is that it's really extremely difficult to develop a plausible set of storage release criteria and validation tests with the current situation. If we map out all the possible paths through the 'non-custom' path it still comes out to something like 80, given the current level of choice, and it's pretty impractical to test 80 different routes at every TC/RC build. Or even at every milestone. So if we don't change the design, QA is effectively forced to test only a reduced subset of the 'non-custom' path choices, whether we *plan* to do that or we pretend we're going to test them all but, inevitably, don't. Yet the installer design doesn't really communicate in any way that some paths through 'non-custom' install are more tested/reliable than others. Anyhow, that's kind of where we left off back in December or January, and we probably really ought to get around to looking at this again - and, as I said, incorporating the perspectives of the different Product WGs and the question of variant anacondas (whether any of the Products actually wants one, and if so, whether that's actually viable) pretty soon. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 3

how to build initrd.img、efiboot.img after anaconda-16.12.1
by 夏磊 14 Feb '14

14 Feb '14

Hi, all I find that these scripts, buildinstall、buildinstall.functions、mk- images.efi 、mk-images.x86 in anaconda source(anaconda/scripts) are disappeared after anaconda-16.12-1. These scripts are used to build initrd.img、efiboot.img、install.img, and so on. so, after anaconda-16.12.1, how we to build installer? Thank you very much!

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 2014