Anaconda-devel January 2013

anaconda-devel@lists.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

Anaconda Usability Test Administrators Worksheet
by Stephanie Manuel 25 Jan '13

25 Jan '13

Hi Everyone, I have created a Test Administrators Worksheet for the administrators of the test to have with them during the usability testing. This will help guide them through the installer and have a more structured way of making notes during the testing. I have uploaded it to the wiki here: https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Test_Administrator_Work… I would appreciate it if you could take a look at it and give me any feedback you have. Thank you, Stephanie

3 3

Re: installer final touches matters
by Máirín Duffy 25 Jan '13

25 Jan '13

Please take discussions like these to the installer development list; fedora-devel is too broad a list to discuss mintuae like this I think. On 01/20/2013 05:15 AM, Muayyad AlSadi wrote: > we see 3 items, one of them "no disk selected" > it has the same level of importance as the rest two, > I believe its background or foreground should be made red or orange. Would it help if the bright orange /!\ icon immediately next to it was larger? > choosing the destination is scary, since people know there are some > steps might wipe the entire disk, the screen below needs a way to gently > tell the user that this step is not scare "the monster is not in this step" > > http://i.minus.com/jWQMDfIBvDHZZ.png That's a fair point. > later steps should *tell* the user what to do > eg. delete a partition then activate auto partitioning > or create an ext4 mounted as / > > always tell the user what is the problem and how can he/she fix it Unfortunately, Anaconda can't read the user's mind as to what the user is looking to achieve, but if you aren't trying to do something advanced or complicated you'll be led through the guided installation path which is very well documented and has a lot of explanatory language to guide the user through. I noticed you didn't include screenshots of any of that. ~m

5 7

[usability test] Need feedback on LVM & RAID task diagrams
by Máirín Duffy 25 Jan '13

25 Jan '13

Hi folks, I put together some diagrams of LVM and RAID layouts to ask the usability testers to try to assemble in Anaconda so Stephanie can add them to the usability test plan. If you wouldn't mind, can you look these over for me and let me know if these make sense? I did successfully complete installs on a VM using these configurations and the numbers add up right and they do seem to work fine: LVM: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Usability/Tasks/LVM-Config… RAID: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Usability/Tasks/RAID-Confi… Thanks in advance for any feedback! ~m

3 5

"'Wow' for anaconda" !
by Máirín Duffy 24 Jan '13

24 Jan '13

You did a fantastic job, everybody! Remember this article when you read the next bug report :) === "Fedora 18 revisited: Cinnamon, Xfce, LXDM, and a 'wow' for anaconda" by J.A. Watson on ZDNet http://www.zdnet.com/more-on-fedora-18_p4-7000009990/#photo "I've been rather blunt in my comments and criticism of anaconda, both here in my own blog and in comments I've posted elsewhere. But on reflection, I think it's important to remember that writing a program like anaconda is a huge task: it's extremely complex and absolutely full of variations, different paths to the final goal (installing Linux), tons of minute details, every one of which has got to be exactly right. And the complexity is increasing, not decreasing. Get anything wrong, often even in the smallest detail, and you end up with a failed install — or even worse, with an unbootable or even wiped disk or an otherwise unusable system. I have never worked on or contributed to anaconda (other than flippant criticism), but from having been on other such projects I can tell you that you seldom hear about how well you have done, but you always hear (generally at high volume) when something goes wrong. "So I want to say right here and now, loud and clear, WOW. What a good job. For this to be the first release of a complete redesign and rewrite of anaconda, and for it to be this solid, is extremely impressive. Those of us who know Fedora will know that this is not the 'last' version, it isn't 'cast in concrete', it's going to continue to develop and improve, and future releases will be even better. But this first release works, and works quite well." ~m

4 3

Anaconda Proposal: Implement additional UPDATES kernel parameter variations
by Reartes Guillermo 22 Jan '13

22 Jan '13

I have the following proposal for the 'updates=' (anaconda) boot parameter: * updates=<url> This is the current 'updates' boot parameter. <URL> = Image containing updates over FTP or HTTP. * updates=latest This proposed boot parameter makes anaconda get the latest version of anaconda (POST-RELEASE) UPDATES image from the standard location. (Requires internet). This will make possible for Anaconda developers to issue hot-fixes for post release, if they see fit for it. (A new criteria for those hot-fixes may be needed). Example of standard location: http://dl.fedoraproject.org/pub/fedora/linux/updates/installer/f18-latest-a… Additionally: An extra boot entry could be added to Fedora ISO, under 'troubleshooting' (since it should not be done by default). The boot entry can be named 'Update the installer to latest version and install Fedora'. Such entry could make use of the proposed boot parameter 'updates=latest'. This will make easy to update the installer from the media. (no need to type URLs). * updates=ask This is a bit overkill, but it might be possible to do it. When one ask for an updates, anaconda will present a list to select a specific version of the UPDATES image. If will query only the standard location. In the standard location, these files might exist: http://dl.fedoraproject.org/pub/fedora/linux/updates/installer/f18-latest-a… (points to u003) http://dl.fedoraproject.org/pub/fedora/linux/updates/installer/f18-18.40.2-… http://dl.fedoraproject.org/pub/fedora/linux/updates/installer/f18-18.40.2-… http://dl.fedoraproject.org/pub/fedora/linux/updates/installer/f18-18.40.2-… So anaconda will present a menu: Select the UPDATES Image from the list: 1) Anaconda 18.40.2-u003 (default, just press ENTER) 2) Anaconda 18.40.2-u002 3) Anaconda 18.40.2-u001 4) Do not update Anaconda, use the version included in the current media. Thanks in advance.

2 1

Anaconda Proposal: UPDATES IMAGE: Identity the UPDATES IMAGE
by Reartes Guillermo 21 Jan '13

21 Jan '13

I have this proposal: The objective is to make clear to the user and the developers that the stock anaconda version was not used and an UPDATES images was used instead. 1. First a 'string' should be set/defined in the UPDATES image. Example: "F18-TST-JOHNDOE-20121010-1.1" When one boots anaconda using any UPDATES IMAGE, anaconda should display the string at two places: * First, in TEXT mode, before anaconda graphical UI stars. (Maybe in yellow) "Using an UPDATES Image: F18-TST-JOHNDOE-20121010-1.1" * SECOND, in GRAPHICAL mode display at the upper left corner of them MAIN HUB. Append an "UPD" (or a special mini-icon or a visual clue to the developers) to whatever is shown. Any 'screen-shot' taken will show that an UPDATES image was in use and not the stock installer. (The specific version information will be on the logs). An icon or symbol might be better for the graphical UI than the specific string (for aesthetic reasons). Thanks in advance.

5 4

Anaconda package and gnome requirements
by Martin Sivak 14 Jan '13

14 Jan '13

Hi, the new firstboot (inital-setup) will require anaconda. That will cause all anaconda dependencies to be pulled into the installed environment. And KDE or Xfce based installs will get a lot of unnecessary gnome clutter this way. So I would like to know where exactly do we need Gnome specific packages (metacity I know about.. are there any others?) and if we can remove those pieces to anaconda-gnome subpackage or lorax itself. For example with metacity, we could require only window manager alias instead (like the old firstboot does). Both Anaconda and inital-setup will then use that alias to start it's window manager (which would point to metacity in Anaconda and to whatever is installed in inital-setup). Lorax will make sure that the proper window manager is installed and configured in the installation environment. -- Martin Sivák msivak(a)redhat.com Red Hat Czech Anaconda team / Brno, CZ

3 3

Feedback on installer/storage survey for usability tests (Draft 2)
by Máirín Duffy 11 Jan '13

11 Jan '13

Hi folks! Based on your very helpful feedback from the last thread, Stephanie put together another draft of the usability pre-test survey. It integrates a lot of your feedback plus some of the questions from Filip's survey. The draft is in PDF format this time because some of the layouts we have in the survey would fall apart in plain text - apologies for that, we know it's not possible to comment in-line now. The survey draft is available in PDF and ODT format, the PDF is here (ODT in the same directory): https://linuxgrrl.com/fedora-ux/Projects/Anaconda/Usability/Pre-Test%20Ques… If you have time to take another look and help us sanity-check the survey, we would really appreciate it. Remember that this survey is for usability test participants to fill out before they take the usability test, and the goal of it is for us to get more information about the testers' backgrounds to help inform our interpretation of the test results. It's not meant to be a general usage survey (which we could do as well, but it would be a separate thing and likely run online instead of on paper like this will be.) Thanks! ~m

3 2

FUDCon session on newUI
by Adam Williamson 11 Jan '13

11 Jan '13

Hey, folks. Just a heads-up: I proposed "An introduction to the new Anaconda" as a barcamp session for FUDCon Lawrence: https://fedoraproject.org/wiki/FUDCon:Lawrence_2013#Technical_sessions_.28F… it seemed like a good thing to do, and I suspect it'll be popular. That title is the entirety of my current material. If anyone else wants to take the session over from me or co-present it, please let me know, I'll happily defer to anyone who was actually involved in writing the thing. If not, er, it'd be nice if at least one anaconda team member could show up so when people start throwing rotten fruit I can point them at you and slip out the back door :) thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

1 0

Feedback on installer/storage survey for usability tests
by Máirín Duffy 09 Jan '13

09 Jan '13

Hi folks, I'd like to introduce you to two new contributors who are going to be helping us put the new Anaconda UI through some usability tests: - Meet Stephanie (cc'ed), who is my UX intern through the Outreach Program for Women [1] for the next few months. She is a computer science & engineering student from the University of California Merced. Her internship project involves helping us evaluate the usability of the new Anaconda UI. - Meet Filip (also cc'ed), who is a student working on a diploma thesis in usability testing & tooling. He is friends with Jaroslav Reznik and is going to be helping us with the usability testing plan, and he is also going to be helping us on the ground running some tests at DevConf.cz. One important part of a usability testing plan is giving the users who will be running the tests a brief survey to understand their background and technical experience with respect to the software being tested. Having this information about the testers will help us better interpret the test results. Stephanie has put together an initial cut of the survey we'll be handing to users before they take the Anaconda usability test. We're looking for some feedback on the survey itself - we don't need your answers to the survey, just comments on the structure / content of the survey itself. :) The specific kind of feedback we are looking for is as follows: - Did we miss any key technologies in the lists of questions to ask? - Is any of the wording inaccurate or technically incorrect? - Are there key technical experience or demogrpahic questions that would affect a user's experience through the interface that we should be asking and aren't here? I've pasted the latest survey draft below - please let us know your thoughts! Thanks, ~m [1] https://live.gnome.org/OutreachProgramForWomen SURVEY DRAFT ============ 1) Please circle which of the following age ranges applies to you: < 18 18-25 25-30 31-35 36-40 41-50 51-60 61-70 70+ 2) How often do you use computers and for what reasons? (circle all that apply) I don't use computers often. I use computers for work. I use computers at home. I know how to program. 3) How much experience do you have with any system administration? Novice Moderate Advanced 4) Do you have experience installing any Operating Systems? Which ones? Fedora Red Hat Enterprise Linux Other Linux ________ Apple OS X Windows 7 Windows XP Other Microsoft Windows ________ Other ________ 5) Do you have experience installing any Virtual Machines? Which ones? QEMU/KVM Xen Microsoft Hyper-V Parallels Virtual PC VMware Other ________ 6) What different file systems are you familiar with? (circle all that apply) ext2 / ext3 / ext4 btrfs VFAT NTFS XFS HFS / HFS+ Other ____________ 7) Have you used any of the following networked file systems? NFS NFSV4 SMB/CIFS Ceph Gluster Lustre 8) Do you have experience with advanced storage technologies? a) If so, which kinds? (circle all that apply) iSCSI Fibre Channel Multi-path Storage FCoE IBM ZFCP/DASD Firmware RAID Other ________ b) If so, do you have a preferred storage vendor? EMC Dell NetApp IBM Other ________ 9) How much experience do you have with Logical Volume Management (LVM)? (circle one) I've used it before as an automatically-selected / default storage option I've customized it manually before I've resized LVs before I've managed LVM storage across multiple machines 10) Do you prefer to configure software RAID? Yes No If so, please specify: RAID 0 RAID 1 RAID 4 RAID 5 RAID 6 RAID 10 RAID 0+1 RAID 1+0 11) If you customize your storage configuration when installing Linux, how many disks, what kind of layout, and what technologies do you most often use? (Please draw a diagram of how you would set this up) 12) Do you have any other comments about file and storage technologies that you want to share?

9 19

Fedora 18 issues with translations and keymaps
by Adam Williamson 07 Jan '13

07 Jan '13

Hey, folks. I'm not really sure how to frame it, but the result of all my poking about at keyboard layout bugs and related stuff recently is that I'm pretty sad at the state of support for anything-but-U.S.-English in Fedora 18. Here's the tally: * https://bugzilla.redhat.com/show_bug.cgi?id=889562 - systemd conversion from xkb to console layouts fails probably more than it succeeds, when it does, you wind up with U.S. English as your console layout, not whatever you picked during installation * https://bugzilla.redhat.com/show_bug.cgi?id=891487 - anaconda doesn't seem to manage to offer all the keyboard layouts it could do, and some of the ones it's missing are somewhat important * https://bugzilla.redhat.com/show_bug.cgi?id=891489 - anaconda's mapping of 'native' layouts to user's chosen install language doesn't work in all cases * https://bugzilla.redhat.com/show_bug.cgi?id=878433 (?) - GNOME has a weird predilection for coming up with the obscure 'Bambara' layout in user sessions after an install in a non-English language, but not the correct layout for that language * https://bugzilla.redhat.com/show_bug.cgi?id=881624 - X and GNOME keyboard layouts revert to U.S. English on upgrade to F18 * https://bugzilla.redhat.com/show_bug.cgi?id=854557 - the 'layout testing' in the keyboard spoke doesn't work at all how you'd expect it to * https://bugzilla.redhat.com/show_bug.cgi?id=882440 - in fact, people have various problems interacting with and understanding the keyboard spoke at all, really. Several of the issues discussed in this bug are 'greatest hits', especially the lack of a default layout switch command, the fact that anaconda doesn't automatically start using a layout you promote to the top of the list, and the lack of any kind of indicator in anaconda as to what layout is in use * https://bugzilla.redhat.com/show_bug.cgi?id=859641 - we're picking the wrong default keyboard for Dutch, apparently * https://bugzilla.redhat.com/show_bug.cgi?id=867110 - ...and German (Switzerland) * https://bugzilla.redhat.com/show_bug.cgi?id=885345 - ...and Dutch (Belgian) (there's a few more along those lines which I won't bore anyone with) In addition to those bugs, we have fairly significant regressions in the completeness of anaconda translations between Fedora 16 and Fedora 18 (the numbers for F17 for some languages are weird - a lot of languages show 55% completion for F17 but 90-100% for F16, which seems bogus, as I'm sure things didn't change that much between F16 and F17, so I'm just using the F16 numbers. I assume there's some weirdness that explains the odd 55% numbers for F17, but if not, hey, F17 was kinda boned too...): Language F16 F18 Finnish 93% 75% Indonesian 100% 33% Kannada 94% 33% Oriya 94% 27% Telugu 94% 32% Bengali (India) 93% 33% Portuguese 100% 36% Persian 95% 27% Malayalam 78% 20% NorwegianBokmal 92% 55% Bengali 93% 33% Sinhala 93% 27% Serbian 81% 23% Serbian(Latin) 81% 23% Hebrew 83% 22% Catalan 68% (98% F17) 25% Latvian 88% 20% Greek 68% 21% Turkish 79% 21% Maithili 67% 18% Asturian 85% 24% (from https://fedora.transifex.com/projects/p/anaconda/ ) There are several others around the 50-70% complete mark for F16, too, I just cut off at 67%. It's a fairly long list of languages for which we previously had tolerably complete translation coverage, but we now have a level which isn't really usable: basically these languages have gone from 'covered' in at least F16 (probably F17 too) to 'not covered' in F18. I want to stress I'm not blaming anyone for this: I don't see how it could be otherwise, the problem is the huge amount of string churn caused by newUI, I'm actually more amazed at how many languages _do_ have close-to-100% translations for F18 than how many _don't_, given the conditions. It's just an unfortunate thing. anaconda does not list every available translation for the user to choose from, but I cannot figure out for the life of me how the decision about which to display is made: it's not that very incomplete translations are left out, as plenty of very incomplete translations (including most of the above) are shown. If we filtered out very incomplete translations we might at least look a bit less silly, but we don't seem to be doing that. Our language selection screen is definitely writing checks that our translations can't cash :) I don't really know where we need to go with this, exactly, but a few questions arise naturally: 1. In the short term, is the combination of all these factors enough for us to want to delay F18 further to try and make things suck less? 2. If not, do we want to engage in some Messaging around the F18 release to emphasize that we know there are all these issues and we'll try to smooth things out for F19? 3. In the longer term, how can we get anaconda, i18n, systemd, GNOME etc folks all pointed in the same direction and working so that there's far less suckage and far more smooth interaction going on here? Should we try and run some sort of session at FUDCon? Thanks, folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

10 15

RAID levels not intuitive in anaconda GUI
by Marian Ganisin 02 Jan '13

02 Jan '13

Based on recommendation moving discussion from bug https://bugzilla.redhat.com/show_bug.cgi?id=874068 to anaconda-devel-list. Initial posts can be found in that bug. If you are willing to discuss my notes, please keep me on cc list as I am not subscribed in anaconda-devel list. Thank you. >To address the concerns you specifically wanted explicit addressing: > >> * multiple usage of term redundancy/redundant for few checkboxes. > >The term 'Redundancy' is used once on the RAID configuration screen, I'm looking at the screen now. It is used once, not multiple times. If that isn't what you meant, please clarify. On this screenshot (attached to original bug): https://bugzilla.redhat.com/attachment.cgi?id=640017 First checkbox has label 'Redundancy', last checkbox has label 'Redundant'. In my understanding same terms. Additonally they aren't different by any means, just two equivalent checkboxes for 'redundancy' in same group. Btw that 'RAID6' label visible on the screenshot does not bring any light to selected configuration. >> * error detection is feature of all RAIDs but RAID0, levels can't be >> differentiated > >This is incorrect, Marian. Neither RAID0 or RAID1 have error detection. > >https://en.wikipedia.org/wiki/RAID#Standard_levels Linked section does not seem to mention error detection for any RAID level at all (maybe following table, however that clearly states RAID1 is able to detect/tolerate failure of n-1 drives which is far away best error detection/correction from all other levels). Contrary last sentence of top-level initial paragraph of same wiki page clearly states: RAID levels > 0 provide protection against unrecoverable (sector) read errors, as well as whole disk failure. Additionally md manual page (try man md or read http://linux.die.net/man/4/md ) states exactly same in section RECOVERY: If the md driver detects a write error on a device in a RAID1, RAID4, RAID5, RAID6, or RAID10 array, it immediately disables that device (marking it as faulty) and continues operation on the remaining devices. Marian is right, wiki as well as man md agree with him, all RAID levels except of RAID0 do error detection. Therefore I say that usage of term 'error detection' is highly confusing as it actually counts wide range of RAID levels, RAID is error detecting redundant composition of disks by definition (once more, many professionals do not count RAID0 to RAID family). >> * concern that 'common terminology' used in anaconda is not used anywhere else. > >If you read comment #10 again, you will see I wrote the following: > >in the RAID # format ("common terminology"). > >I was referring to the RAID # format (RAID ), RAID 5, RAID10, etc) as the "common terminology" as that was what Martin called it in comment #0. This confusion is caused by insufficient description of my intention, that's my fault sorry for that. I'll try to correct it. I absolutely agree with initial reporter of reffered bug, Martin Banas, that common terminology is crucial for easy adoption of new RAID handling. In my opinion it is absolutely necessary to bring similar naming as other products providing RAID capability such as BIOS RAID, full featured RAID controllers or other operating systems. I am afraid that terminology introduced in new anaconda isn't used by any similar product and as such it tends to be highly confusing (it is highly confusing to me for all expressed reasons). Therefore I asked to show usage of approach also in other products. I hope it is much clearer now. Well, this is it. Last but not least initial message of bug https://bugzilla.redhat.com/show_bug.cgi?id=874068 describes issue with current implemetation of RAID definition in really specific comments as is and it does not deserve to be closed/rejected without further discussion/research. As the anaconda implements creation of MD devices it would be really nice to have it aligned with MD terminology as expressed in relevant man pages. Thank you very much for audience. Regards, Marian

3 6

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