Anaconda-devel January 2013

anaconda-devel@lists.stg.fedoraproject.org

29 participants
22 discussions

UI idea: summary screen when re-entering the storage spoke?
by Adam Williamson 27 Feb '13

27 Feb '13

Another UI idea, while I'm looking at the storage UI: Would it be nice to show a new screen that summarizes the currently-planned disk layout, if you click the Installation Destination spoke again after having run through it once? I think this might be useful. It would just be a new screen prepended to the storage workflow which shows some kind of summary of what's currently planned so far as storage changes go, and then gives you the options 'That's fine, back to hub!' or 'On second thought, let me re-do that...'. WDYT? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

2 1

Anaconda usability test rough plan for Devconf.cz
by Máirín Duffy 20 Feb '13

20 Feb '13

Hi folks, Stephanie is going to be working on the final touches (fixing typos, adjusting typography, etc.) of the survey for the anaconda usability tests this week - thank you very much for all of the helpful feedback on list. I wanted to share with you a potential rough plan for the usability test at Devconf, and I'd like to ask for your feedback on that as well. Stephanie, Filip, and I have talked about given the time we have allotted at Devconf, we'll probably run two rounds of tests, with four users in each round. So we'll have 8 usability testers total. We talked a little bit about the type of users we'd like to have test anaconda, which I think was cc'ed to this list, but for easy reference they are as follows: 1) Novice users who may be new to linux who just want to install a desktop system 2) Experienced linux users who may dabble in system administration, are very technical, and like trying out different technologies 3) Professional system administrators who work with advanced storage devices and configurations, typically on the job, not for fun Since installing Fedora without customization is the most basic thing a user can do, and it is so critical that any user be able to do that, we talked about recruiting 4 "novice" (#1 above) users to do basically just that - we'll hand them a Fedora disk (or point them at an ISO file) and simply ask that they install Fedora, with no special requirements or customizations needed. We also talked about recruiting more technical users ("experienced" and "professional" / #2 & #3 above) for the remaining 4 slots. Since there are a lot of features and paths someone could take through Anaconda without unlimited time and testers, I would like to propose giving each of the 4 'technical' testers each their own version of the test, each one dealing with a particular feature of Anaconda: 1) Dual-boot: provide the user with a VM that has Windows installed, and see if the user can install Fedora alongside it without wiping Windows. How we do this depends on whether or not the shrink/resize partitions UI is available - did we drop it for final? 2) Customized LVM: provide the user with a diagram and writeup of a specific LVM layout we'd like him or her to use while installing Fedora. 3) Customized RAID: provide the user with a diagram and writeup of a specific RAID configuration we'd like him or her to use while installing Fedora. 4) Preserve /home: provide the user with a VM that has Fedora 17 installed on it with a separate /home directory, and see if the user can install Fedora 18 on top of Fedora 17 without wiping the /home directory from Fedora 17. Some scenarios we are leaving out here: - BTRFS configuration - there's actually a bug that is in F18 gold that complicates BTRFS installations (https://bugzilla.redhat.com/show_bug.cgi?id=893758) so it might not be a good idea to include this anyway. - text mode UI - I think having 4 folks who are not American & native English speakers (the default setting for the UI now is English / us-en keyboard) is much more valuable than having one or more of them split off and do a text mode UI. We can test the text mode UI when we run tests where I am here in Boston if need be. - no network case - Another lower priority test case that I can cover in Boston later on. In case this explanation is confusing, here's a user-by-user rundown of what the usability tests at Devconf should look like: - User #1: novice user, given free reign of installer with simple task of installing Fedora 18 to a VM. - User #2: novice user, given free reign of installer with simple task of installing Fedora 18 to a VM. - User #3: novice user, given free reign of installer with simple task of installing Fedora 18 to a VM. - User #4: novice user, given free reign of installer with simple task of installing Fedora 18 to a VM. - User #5: professional/experienced linux user, asked to install Fedora 18 alongside pre-existing Windows install. - User #6: professional/experienced linux user, asked to install Fedora 18 using a specific LVM configuration. - User #7: professional/experienced linux user, asked to install Fedora 18 using a specific RAID configuration. - User #8: professional/experienced linux user, asked to install Fedora 18 while preserving the /home from a previous Fedora 17 install. Do you think this high-level, basic test plan makes sense? Are there higher-priority test cases we're missing here, do you think? Do you have ideas on how we might be able to run some of these tests using a VM, or do you foresee any issues with making some of these test cases possible at Devconf? As always, feedback/advice very much appreciated. ~m

8 17

Anaconda Usability Test Draft Test Scripts
by Stephanie Manuel 12 Feb '13

12 Feb '13

Hi everyone, First of all, I would like to thank you all for your feedback and suggestions for the pre-test survey. If you haven't taken a look at it yet, the final draft can be found here: https://fedoraproject.org/wiki/Anaconda/UX_Redesign/User_Survey Now that I'm finished with that, I am working on the usability test scripts that will be used during the Anaconda usability test. I would like some feedback on the test scripts I have written so far. What do you think I should add? What needs improvement? All feedback is greatly appreciated and will be a huge help to me. :) The first draft of the test scripts are here: https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Usability_Test_Scripts Thanks, Stephanie

4 8

post-f18 newui TODO
by Chris Lumens 07 Feb '13

07 Feb '13

I guess we might as well start assembling a list of things we need to do after F18 goes out. Here's what I've got: * Put advanced storage (filtering, multipath/iscsi/zfcp dialogs) back in. * Make system-config-kickstart work again. It's been broken since I got rid of iw/GroupSelector.py (#859928). * Add keyboard accelerators to pretty much everything, breaking all kinds of strings in the process (#864964). * Move us to using mutter (or something like it) so we don't get all the redraw ugliness (#858684). * Review Allan Day's suggestions, see what we can and cannot do, do it. * Review the Wall of Anaconda, see what we can and cannot do, do it. * Work on making our threading a little less awkward. In particular, it can be very hard to tell what thread a method is executing in, and whether or not you can do GTK calls directly. We also could use thread name constants (wasn't someone else already working on that?). * Allow selecting multiple disks (#864707). * Allow a faster way of deleting everything on a disk (#880686). - Chris

5 6

RFC: Blivet & mounting
by Jan Safranek 04 Feb '13

04 Feb '13

Hello, OpenLMI project uses Blivet, former Anaconda storage library, to manage storage. Management of storage also means management of mounts, i.e. ability to mount/unmount/remount stuff, list existing mounts and add/delete/modify/list entries in /etc/fstab. The installer somehow manipulates fstab and mounts stuff and there is some code in Blivet for that, but I am not sure it can be easily extended for generic use case. Is generic mounting/unmounting capability that something Blivet should do, so it would be integrated there, or there should be separate library for this? In both cases, we (=OpenLMI) would /probably/ provide the code. Is there any other potential Blivet user who needs mounting? Can the installer benefit from more generic mounting? What OpenLMI needs: - parse /proc/mounts and provide list of mounts with their options - parse /etc/fstab and provide list of persistent mounts with their options (which can be different to /proc/mounts, someone might re-mount something with different options!) - re-mount a mount with different options - create new mount, both permanent (with fstab entry) and 'temporary' - unmount anything (incl. removing entry from fstab). BTW, for fstab manipulation I am thinking about augeas-python. It does not pull any big dependency except libxml2, still it's yet another package needed in installer ramdisk if generic mounting is in Blivet. Jan

2 1

Few ideas for Anaconda hub and spoke
by Zoltan Hoppar 02 Feb '13

02 Feb '13

Hi, I have gathered several ideas for hub and spoke - maybe it's can be useful for the next release of anaconda... So here we go: 1. Make it possible to see all spoke modules at the hub as start. 2. Hub and spoke modules in anaconda is great, but it needs hub and spoke for the kickstart too. Every spoke module has to provide an kickstart file what the hub can execute or skip as the user wants/selects. Instead of rewriting every time the kickstart why couldn't be modular? 3. The installer SHOULD *only* provide an small LIVE core (200-300 MB) of the system that bootable in any circumstance till bash, and ready to use in CLI or for futher customization (Possibly JUST minimal install). With the small core - what is easily maintainable 4. Separate the installation parts to different spoke modules. Eg. I think we need an spoke module, where you can select your default UI (Gnome, , and customize its apps if the user wants. 5. Make it possible that after hw detection - witch hw has no driver - be presented in the central hub, and if the user has an driver that the manufacturer provides, be possible to insert it from externally. Debian has this feature from eons in Squeeze installer. 6. After I have seen tons of post installation apps (Fedora tools, Easylife and whatnot), where you can select extra applications, I would like to suggest something else. Instead of selecting one by one the needed apps, I'd like to see package groups for different use cases inside an spoke module. Make it possible to save it externally, and reuse it when installing next time. This can include even backups, and home folder files, settings - I think. On desktop, I think we should offer an desktop customization directly as we start after question "Would you like to set your final customization?" the settings panel with tiny description window as "We open for you the control center where you can finish your desktop customization if you wish, if you say here later, you can call the control center/settings panel any time with .... and thank you for selected Fedora XX codename.". Thanks, HTH, Zoltan -- PGP: 06853DF7

6 6

selecting a kernel to install
by David A. Marlin 01 Feb '13

01 Feb '13

I've encountered an issue with the kernel selection when building disk images using livemedia-creator. Note: I am working with ARM systems. The issue is, when making an image and passing "None" as the armPlatform (base kernel install), it seems to pick the wrong kernel. The correct choice in this case is kernel-3.6.10-8.fc18.armv7l, but instead kernel-kirkwood-3.6.10-8.fc18.armv5tel is installed. I'm not sure why a 'kirkwood' kernel (flavor) would be selected over the base kernel of the same version, but I suspect it has something to do with the arch (armv7l and armv5tel). Both are Soft-Floating Point kernels, but only a base kernel should be installed if the armPlatform is "None" (at least, that is the intent). This issue does not arise on Hard-FP systems (it works as it should), but all Hard-FP kernels are the same arch (armv7hl). If anyone has ideas why this is happening, or has suggestions for debugging the issue, I would appreciate your feedback. For reference, the command line I'm using is: livemedia-creator \ --make-disk --no-virt --image-only --keep-image \ --armplatform=None \ --ks=<PathToKickstart>/F18-vexpress-xfce-sfp.ks The kickstart file does not specify any specific kernel or version. Thank you, d.marlin

2 1

Couple of issues with the bullet point list when no partitions exist in custom partitioning
by Adam Williamson 31 Jan '13

31 Jan '13

In response to https://bugzilla.redhat.com/show_bug.cgi?id=883150 , clumens added more or less the bullet point list that I proposed (thanks!) to the custom part screen, when the user has not yet created any partitions for the new install. However, I noticed a couple of problems, looking at 19.2: http://www.happyassassin.net/extras/bulletpoints.png * There's an awful lot of horizontal padding in the bullets. Can we compress that at all? It looks awkward, and if we compress it a bit, we should be able to lose two or three lines vertically in English (each of the bullets wraps onto an extra line by only one or a few words). * The "Or, assign new mount points to existing partitions after selecting them below" bullet should be suppressed if there are no existing partitions, if that's possible. thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

3 4

alternatives for bootloader --password ?
by Gabriel L. Somlo 28 Jan '13

28 Jan '13

I run a student lab of Fedora machines, and have taken various steps to eliminate unwanted modifications by users (physical case locks, BIOS password, GRUB password, reduced PackageKit and ConsoleKit privileges for console users, etc). I also like to be able to openly publish my kickstart file(s), and have therefore avoided including any passwords in it (and managed to do so successfully in F16). With F16, I could comment out the "bootloader" line in the kickstart file, and have Anaconda provide a bootloader dialog which included the ability to enter the bootloader password interactively (similarly to how the system root password is handled). With F18, I noticed that's no longer possible: leaving out "bootloader" in kickstart seems to result in an unbootable system, and the only available method to lock GRUB is to provide a '--password' option to the "bootloader" line within the ks file itself. I'm wondering what other alternatives there might be for --password in future versions ? Would it be reasonable to e.g. reuse the system root password in GRUB (e.g. "bootloader --location=mbr --boot-drive=sda --use-root-pw") ? The default username created by Anaconda (in /etc/grub.d/01_users) is "root", and the person/group with privileges to edit/modify the boot parameters is most likely the same as system-root (I'm having trouble coming up with scenarios in which that's not the case), so the security posture would be most likely unaffected by this. Of course, restoring the ability to have an Anaconda dialog for the bootloader password would also be nice, if the above turns out to be hard, or a bad idea for reasons I can't think of right now. Please let me know what you think (and I'm missing anything obvious). Thanks much, --Gabriel

1 0

Anaconda and 800x480 resolution issues (early netbook)
by Reartes Guillermo 28 Jan '13

28 Jan '13

Hi, I filled these bug-reports regarding the issues i found with my EEE 701. It is possible to install F18 on such device, but it is highly recommended to do so with an ethernet cable plugged in the onboard network card. Anaconda: netbook resolution 800x480 issue with the network spoke (right after the welcome screen) Bug: 904989 Anaconda: netbook resolution 800x480 issue with the network spoke (from the main hub) Bug: 904991 Anaconda: netbook resolution 800x480 network spoke: configure button is too tall Bug: 904994 Anaconda: netbook resolution 800x480 manual partitioning screen issue (can be repaired most of the time) Bug: 904999 Anaconda: Anaconda: issue with the network spoke disable/enable wireless duplicates the wireless device Bug: 905004 Cheers.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel January 2013