Anaconda-devel October 2013

anaconda-devel@lists.stg.fedoraproject.org

24 participants
17 discussions

Idea for making custom partitioning more accessible
by Máirín Duffy 23 Dec '13

23 Dec '13

Hi, Some user feedback and usability testing we've done indicates that having custom partitioning accessible only by a pop up dialog attached to the 'done' in the storage spoke is confusing - people search for custom partitioning on the first storage spoke screen, don't see it, give up and hit done, then they see it. I think we should consider providing a better pathway to it on the main screen rather than hiding it on the dialog. I think I was overzealous in trying to shield less-technical ("non-Pokemon") users from it in the original mockups and unnecessarily hurt the users wanting to access custom part. We had a discussion about this in IRC today, and after a few iterations (we started with http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… and iterated from there) I put some more work into a set of mockups that might work. The thing is, it's hard to just add a button here or move something there without affecting a lot of other things - in this case, the display of the dialog on exit from storage entirely and the encryption and autopart type options. Okay so here's a little walkthrough: AUTO-PART USER ============== 1) You click on the storage spoke icon and you see this: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… You might opt-into disk encryption, and you leave everything else alone. 2) You click 'Done' in the upper left corner. You go straight to the hub. Yeh. So basically: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… Anything you would have been able to do in the dialog you already did in the main window. Except for choosing auto-part type. If you're not going into custom part, is the default auto-part type good enough? If not, the main screen design will need more thinking. CUSTOM PART USER ================ 1) You click on the storage spoke icon and you see this: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… 2) You click on the radio button that says "I will configure partitioning" and hit Done. Then you'll see this: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… You pick the auto part type you want in the dropdown and hit create to let it do its thing and then tweak accordingly. Or you can start from scratch if you're into that. 3) You click on the 'done' button in the upper left corner of custom part and it does the same as it does now (summary of changes, then back to the hub) RECLAIM DISK SPACE POP-UP ========================= Just a small mod to this one, since encrypt and autopart type are available else where, drop them: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… NO DISK SPACE POP-UP ==================== No changes to this guy: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… Does this make sense? I know Chris had concerns about having two columns of options on the screen because translations can get lengthy, so I cut the text length substantially and did a vertical stack of options, but I made the radio buttons horizontally aligned (which the HIG actually allows for, who knew.) I also scaled the disk icon down to 96x96, although 64x64 might work better (need to account for icon height of network disks too.) The only sticking point here is that auto-part folks won't get to choose their flavor unless they go into custom. But maybe it's good, people who don't really know the difference won't have to even make the choice. And it's easy enough to go into custom, hit auto part for the flavor you want, and get out? Thoughts? ~m

7 12

GPT (and ultimate UEFI)
by Gene Czarcinski 13 Nov '13

13 Nov '13

One of these days, we are going to get GPT partitioned disks good, bad, or indifferent. In "regular" install mode with automatic configuration, the "bootbios" partition is automatically allocated. In "regular" install mode with custom configuration, you cannot proceed until a 1MB "bootbios" partition have been comfigured. [I am not sure if this has to be the first thing configured or not.] So, what should be done with kickstart where gpt is specified as the kernel parameter and something like: clearpart --all --initlabel --drives=vda is specified? Alternates: 1. Add option(s) to part for creation of the "bootbios" partitions or (and better) 2. Make allocation of the "bootbios" partition part of "clearpart" processing. I notice that clearpart --initlabel not does "gpt" for itanium. Comments? Gene

5 4

Re: [PATCH] btrfs subvolume reclaim option for kickstart
by Gene Czarcinski 31 Oct '13

31 Oct '13

I was originally going to reply on the patches list but this is more appropriately a discussion so I am moving it over to the discussion list. This is the reason for all my agony over testing. On 10/31/2013 08:13 AM, Gene Czarcinski wrote: > This involves a patch to pykickstart and a patch to anaconda. > > The patch for anaconda was created on anaconda-20.25.4-1 and the patch > for pykickstart was created on r-1.99.44-1 and should easily apply or > rebase. > > The patches implement a capability currently available if you perform a > non-kickstart custom-allocation install where you can reclaim the name > (and space) of an existing btrfs subvolume and then reuse (recreate) a > new btrfs subvolume of the smae name over it. > > The are times in both virtual and real world when a reinstall is needed. > Currently, when this involves a btrfs subvolume as root, you have to manually > delete that subvolume. The capability implemented in these patches allows > a kickstart user to do that at install time. > > Note: "--reclaim" was chosen for the option since it is both different and, > at the same time, the same as the term used in a non-kickstart install. > > NOTE: While I believe that these two patches are good. However, they have > been only partially tested due to problems with pungi/lorax creating ISOs > with working BTRFS! > > Gene Czarcinski (1): > add btrfs option reclaim > > pykickstart/commands/btrfs.py | 4 ++++ > 1 file changed, 4 insertions(+) > > Gene Czarcinski (1): > add reclaim capability for btrfs subvolumes > > pyanaconda/kickstart.py | 8 ++++++++ > 1 file changed, 8 insertions(+) > OK, now that I understand how to create an updates image which includes anaconda changes AND pykickstart updates, I have conducted some additional tests. I have been testing on Fedora 19 although the submitted patches are for Fedora 20 ... they rebase easily enough. The problem: storage.destroyDevice(device) gets an "Attribute error: Blivet object has no attrribute 'destroyDevice' Now, I had done some testing with just anaconda by kluging things up. I changed the if self.preexist: to be if self.preexist and self.mountpoint != "/": and then were I now have: if self.reclam: I then had if self.preexist: The point being that the storager.destoryDevice(device) was the same and I traced it going to destoryDevice() in blivet/__init__ around line 1172. The two patches are below. What is different? This is driving me nuts. ------------------ The Fedora 19 kluge ----------------------------- diff --git a/pyanaconda/kickstart.py b/pyanaconda/kickstart.py index 5bcad3d..287d6c1 100644 --- a/pyanaconda/kickstart.py +++ b/pyanaconda/kickstart.py @@ -343,7 +343,9 @@ class BTRFSData(commands.btrfs.F17_BTRFSData): if self.mountpoint != "" and self.mountpoint[0] != '/': raise KickstartValueError, formatErrorMsg(self.lineno, msg="The mount point \"%s\" is not valid." % (self.mountpoint,)) - if not self.format: # --noformat + # FIXME: The following hack only exists until pykickstart can be updated to separate + # --noformat and --useexisting into separate parameters so they can have different meanings + if not self.format and self.mountpoint != "/": # --noformat if not self.subvol: raise KickstartValueError, formatErrorMsg(self.lineno, msg="Specifying btrfs command for existing volume %s invalid" % self.name) @@ -368,6 +370,16 @@ class BTRFSData(commands.btrfs.F17_BTRFSData): except KeyError: pass + # Handle pre-existing subvol to be deleted + if self.subvol: + device = devicetree.getDeviceByName(self.name) + if device: + if self.preexist: + storage.destroyDevice(device) + log.info("As requested by specified --useexisting, destroying existing BTRFS subvolume %s" % self.name) + else: + raise KickstartValueError, formatErrorMsg(self.lineno, msg="Specified BTRFS subvolume %s already exists, specify --useexisting to recreate" % self.name) + request = storage.newBTRFS(name=name, subvol=self.subvol, mountpoint=self.mountpoint, -- 1.8.3.1 ------------------------------------------------------------------------------------------------------------------------- --------------------The "good" Fedora 19 version ----------------------------------------------------------------------------------------- diff --git a/pyanaconda/kickstart.py b/pyanaconda/kickstart.py index e6ed38d..53d4dd4 100644 --- a/pyanaconda/kickstart.py +++ b/pyanaconda/kickstart.py @@ -387,6 +387,14 @@ class BTRFSData(commands.btrfs.F17_BTRFSData): device.format.mountpoint = self.mountpoint else: + if self.subvol: + device = devicetree.getDeviceByName(self.name) + if device: + if self.reclaim: + storage.destoryDevice(device) + log.info("As requested by specified --reclaim, destroying existing BTRFS subvolume %s" % self.name) + else: + raise KickstartValueError(formatErrorMsg("Specified BTRFS subvolume %s already exists" % self.name)) request = storage.newBTRFS(name=name, subvol=self.subvol, mountpoint=self.mountpoint, -- 1.8.3.1 ----------------------------------------------------------------------------------------------------------------------------

1 0

help ... please
by Gene Czarcinski 31 Oct '13

31 Oct '13

Testing patches made to anaconda is relatively easy given the capability of using an updates image. However, when a change involves anaconda and python-blivet and/or (as in my case) pykickstart, it is more complicated because, to the best of my knowledge, you need to respin an ISO to do the test. Now a bunch of years ago (ten to twelve to be exact) I did do some work requiring that I rebuild the anaconda boot and found it a faily easy thing to do. Time passes and anaconda code has changed. in addition, we now have pungi, lorax, etc. to help us build ISOs. Well, I have just spent the last three days beating my head against the wall. First of all, pungi/lorax does not work well if it is working with anything other than the single rawhide repository -- e.g., it expects the syslinux package (and other packages too) to be in the first repository or it cannot find it and the build fails. Most important for me is that pungi/lorax cannot build an ISO with a working BTRFS. So ... help ... please! Can someone tel me how to make pungi/lorax produce an ISO with a working BTRFS? Or, can someone point me to the software you folks use to build an ISO when you want to test changes to anaconda/pykickstart/python-blivet/etc.? This may not be specifiic software but more of a process or procedure but the current pungi/lorax it is not. Gene

6 9

Fedora 20 Beta blocker bug status: fix and karma requests
by Adam Williamson 27 Oct '13

27 Oct '13

Hi folks, and welcome to the Fedora 20 Beta blocker bug news... The bad news is that we're still some way from a viable Beta RC. We need work on several blockers, all of which is outlined below. I'll start with bugs that need work from developers; QA folks, there are tasks for us listed later on. Accepted blockers - anaconda and python-blivet ---------------------------------------------- * https://bugzilla.redhat.com/show_bug.cgi?id=986575 - "installer fails to apply lower bound to resize requests in custom spoke" - this bug has been open for a while and needs a fix from anaconda team, when they have time. * https://bugzilla.redhat.com/show_bug.cgi?id=1010495 - "Apple Mac EFI: you have not created a bootloader stage1 target device" - this bug breaks the most common installation scenarios for Apple systems (guided install alongside an existing OS X install). bcl has been working on fixing it: back in September he posted an initial patch, then decided that it was not sufficient - https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/00… . There is no information since then that I can find. * https://bugzilla.redhat.com/show_bug.cgi?id=1016959 - "ValueError: Cannot remove non-leaf device 'btrfs.14'" - this is a crasher with certain existing btrfs volumes. dlehman posted a plan on how to fix it, but there is no proposed patch that I can find. Accepted blockers - other ------------------------- * https://bugzilla.redhat.com/show_bug.cgi?id=1000891 - "DVD is oversized (larger than 4.7 GB)" (spin-kickstarts, comps, pungi) - a fix for this was scheduled for TC3, but it caused the DVD compose to break, and was backed out to produce a testable TC4. TC5 continued without the problematic fix (and hence is still over-size). AIUI, dgilmore was supposed to be looking into the compose issue, but I believe he is now on vacation, so we may need someone else to step in: CCing nirik and notting. * https://bugzilla.redhat.com/show_bug.cgi?id=1013767 - "rootfs on thinp not found, startup failure" (dracut) - an update containing a fix for this has been submitted - https://admin.fedoraproject.org/updates/dracut-034-18.git20131018.fc20 - but one reliable tester has reported that it breaks boot on their system, so further developer work may be required here, harald: https://bugzilla.redhat.com/show_bug.cgi?id=1021083 * https://bugzilla.redhat.com/show_bug.cgi?id=1015234 - "F20 Beta TC1 ARM disk images unable to find root filesystem" (dracut) - this bug is marked as an unresolved blocker but has in fact been worked around since, I believe, TC2. We can probably ship Beta with the workaround, and this may just need some Bugzilla Bureaucracy rather than developer attention at this point. Proposed blockers ----------------- * https://bugzilla.redhat.com/show_bug.cgi?id=1020974 - "incorrectly treats a disk with partially corrupt GPT as having no partition at all" (anaconda) - this looks like it could well be accepted as a blocker, so developer attention would be appreciated. * https://bugzilla.redhat.com/show_bug.cgi?id=1005895 - "Upgrade to f20 fails because of deltarpms" (fedup) - Will posted a proposed fix for informal testing; Will, one of the reporters has confirmed the fix is good, so can you please submit an update? Thanks! Bugs requiring QA attention --------------------------- * https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses LVM when Standard Partition is selected in text mode" (anaconda) - this bug has been verified fixed by the update https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anacond… , but that update needs more karma to go stable. That is the build that is in TC5, so anyone who's tested TC5 and found it generally OK (no worse than previous builds) can +1 the update: please do! * https://bugzilla.redhat.com/show_bug.cgi?id=1013800 - "devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool" (python-blivet) - this is believed to be fixed by the https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anacond… update (and hence in TC5). We need to verify the fix and add karma to the update so it can be pushed stable and the bug closed. * https://bugzilla.redhat.com/show_bug.cgi?id=1019500 - "device factories need to set a default name if empty name given for defined device" - exactly the same as 1013800: this should be fixed in TC5, please confirm the fix and up-karma the update. This has been your blocker bug news, folks - if everyone can help out with fixing the remaining issues and testing the anaconda/blivet update, that'd be a great help. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net http://www.happyassassin.net

4 16

PyCon PL 2013 Anaconda slides
by Martin Kolman 24 Oct '13

24 Oct '13

Slides from my Anaconda talk on PyCon PL 2013[1] are available here: http://modrana.org/pyconpl2013/the_anaconda_installer.pdf The talk was being recorded and according to the organizers it should show up online with the other conference videos in about a month. Kind regards Martin Kolman PS.: I've also talked about developing Android application in Python, slides & examples are here: http://modrana.org/pyconpl2013/python_and_qt_for_android.pdf http://modrana.org/pyconpl2013/examples/ http://modrana.org/pyconpl2013/pyconpl.apk [1] http://pl.pycon.org/2013/en/

1 0

patch to improve display of keyboard layouts
by Jens Petersen 22 Oct '13

22 Oct '13

Hi, I wanted to have this patch for some releases now and finally found time now to work on it this week. (Also attached to https://bugzilla.redhat.com/show_bug.cgi?id=1021907) Short summary is that this changes the display of keyboard layouts from "English (English (US))" to "English (US)", ie it avoids the unnecessary repetition. The final patch is actually quite simple, almost simpler than the current code perhaps. It checks is if the translated xkb layout description starts with translation of the language and if so just displays the translated description, otherwise it displays "lang (description)" as now. I feel this makes the layout display less confusing and easier to read so I hope this small patch could be reviewed and accepted for Fedora 20. I have tested it pretty carefully for most of the major languages and it seems to work well. Thanks, Jens

1 0

splash image and the progress bar under it
by Kun Huang 17 Oct '13

17 Oct '13

Hi all The splash image and the progress bar under it occer

2 4

One more translation question
by Gianluca Sforna 16 Oct '13

16 Oct '13

Can anyone help me understand what the following strings in blivet refers to? create format destroy format resize format Thanks Gianluca -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu

2 1

Translation question
by Gianluca Sforna 16 Oct '13

16 Oct '13

While translating anaconda to Italian I noticed there are several instances of the string "custom partitioning" but the corresponding screen in the interface is then titled "MANUAL PARTITIONING" Is this difference intentional? You can probably think this is just bikeshedding, in fact I think I noticed just because the translation for "manual partitioning" is much easier and sound more native than the one for "custom partitioning" By the way, I tried an F20 installation in a VM after several releases where I just upgraded all my machines; you guys surely did a lot of improvements over the first iteration, really smoother than I remembered. Thanks for all the hard work! Regards Gianluca -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu

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 October 2013