Anaconda-devel February 2013

anaconda-devel@lists.stg.fedoraproject.org

26 participants
17 discussions

Boot Loader Spec
by Will Woods 30 Mar '13

30 Mar '13

Hey all - Some clever folks have come up with a draft spec for handling boot configuration in a shareable, cross-bootloader, cross-distro way. The details are here: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec but the basic idea is this: 1) Everyone uses an agreed-upon method for locating /boot 2) Each boot entry is a .conf file in $BOOT/loader/entries/ 3) The .conf files use a common, agreed-upon format And.. that's about it. Simple and elegant. It greatly simplifies adding, modifying, and removing boot entries, and also identifying (and dual-booting) other distros. I'm also reproducing Lennart's original mail below for further edification, but there's a couple things I want to discuss here: === Our role === In this scheme, OS installers are responsible for: * finding (or creating) the /boot partition * finding (or creating) $BOOT/loader/entries * adding an entry for /boot to fstab Mostly this would mean tweaking our /boot-finding Algorithm to match the one in the spec (if it doesn't already!) and automatically using an existing /boot partition if one is found. We should still let users violate the spec if they want, but we should probably warn them pretty hard. === Platform support === The spec gives an algorithm for finding /boot on systems with either msdos or GPT partition maps, which obviously covers i686/x86_64. As for other arches: * arm - All the ARM platforms I know of use msdos. No problem. * ppc - Everything but Apple uses msdos, and we don't support Apple. (The PReP partition is roughly equivalent to the MBR, which isn't relevant to the location of the config files..) * s390 - Has its own special partition map for DASD. Of course. So. Can we come up with an addendum to the /boot-finding algorithm that specifies how to locate/create /boot when using DASD partition maps? === Open questions === A few things I wondered about: * Default entry How does the system choose which entry to boot by default? Or how can we tell the system to boot a given entry just once? This is outside the scope for this spec, but it'll be addressed later. * Handling MBR/PReP What should we do with the MBR/PReP if we're sharing /boot? If we find $BOOT/loader/entries, there will already be a compliant bootloader installed, so we don't need to install a new one. But that also means that we *can* install a new bootloader without harming the other system. Should the spec define which behavior is appropriate here, or deliberately leave that up to us? If $BOOT/loader/entries doesn't exist, well, we just end up with the current behavior (create our own /boot and write our own config into it) so there's no loss of functionality or interoperability there. * Icons and theming If we're sharing a bootloader, whose theme does it use? Or if we had something like the Apple boot picker, wouldn't we want to be able to specify an icon to use for our boot entries? That's probably another future spec, but I'd like to see it addressed.. Anyway. Let me know if you have any thoughts here. The original mail from Lennart is reproduced below. -w ---------------------------------------- Heya, (This mail is intended to the boot loader maintainers in the various distributions. I am not sure I figured them all out correctly, if not, would you be so kind to forward this to the folks who are the actual maintainers? Also, feel free to forward this to anybody you think should be in the loop...) Newer EFI systems generally do not initialize USB anymore at boot, to shove off a couple of seconds of POST. This means no kbd support to enter the BIOS setup or to actually control the boot menu. Currently, the Linux dual-boot story relies on boot menus: if you have installed three linux versions, you choose at boot time where you want to boot into, but that's not going to work anymore for all cases, already now. Currently, dual-booting (or triple-, ... multi-booting) is pretty ugly on Linux anyway. The installers try to probe for other OSes, and then generate a configuration from that, that can't really be updated, and the installers generally fight for which one may possess the MBR. Then, there's no way for userspace to actually figure out which boot options are available, short of parsing grub2.conf. One way to support dual-boot scenarios might be to show a list of other installed OSes in the normal OS UI (i.e. somewhere in the GNOME system settings or maybe the GNOME shutdown button) and allowing the user to click on it to boot into it, but if we can't even figure out which OSes are installed, that's never going to work. So, thinking about this, we came up with this specification: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec This basically defines a scheme how multiple distributions can share a single /boot and hence boot loader, without stepping on each other's toes. It defines a generic syntax for drop-in menu items, which can be read directly by the various boot loaders, and by userspace as well. And it defines a scheme how installers can find where these files are to be dropped, so that they can mount it to /boot. Of course, just discussing the theory of this isn't enough, and hence we sat down and implemented this in Gummiboot (where it is the native configuration format now) as well as Grub2 (the patch is here: http://0pointer.de/public/0001-blscfg-add-blscfg-module-to-parse-Boot-Loade… -- currently only applies to Fedora's slightly older version of Grub2). Now, we are really interested in getting the various distributions to subscribe to this idea. We are looking into support this scheme in Fedora soon, our development packages of grub2 and gummiboot have been updated already for this. Right now, the spec is mostly a draft. We have thought a lot about it, and it should be quite nice already. It covers both EFI/GPT systems and MBR systems. But it's probably time to get more people involved, hence this mail... To make this palatable to many folks we based the spec on grub1's old syntax. Soooo, what do you guys say? Any chance we can get the key distributions on board with this? Any comments? Anything you are missing? Good idea or worst idea ever? (Consider this spec semi-public: feel free to pass it on to whoever you think should now about it, including in mailing lists, but please keep it off blogs, slashdot, LWN for now, thank you). Lennart

7 8

Blivet mounting & fstab
by Jan Safranek 01 Mar '13

01 Mar '13

I briefly checked Blivet and it is currently calls cmdline mount(8). There exists libmount library [1], which could be used to streamline the mounting without forking. Unfortunately, it does not have Python bindings yet, but that can be solved. 1: https://www.kernel.org/pub/linux/utils/util-linux/v2.21/libmount-docs/ I had a brief chat with libmount author (Karel Zak, on cc:) and it would be possible to add fstab editing to the library, so Blivet would get it for free. David, what do you think about? I know, Blivet can mount stuff even now and using a library wouldn't add immediate benefit, but fstab editing could be worth checking. Jan

3 2

supporting boot configuration for 32 bit arm
by Dennis Gilmore 27 Feb '13

27 Feb '13

** Resending with the right lists ** after talking at devconf with David Cantrell about the best way to support setting up uboot on arm devices in anaconda, the best approach going forward is pretty clear, ill get to it in a bit first i want to describe things as I see them. Unified kernel while solving many issues introduces some. platform detection was kinda simple with separate kernels. unified kernel means that while we dont need to worry about having the right kernel, we do need to worry about loading the right dtb. platform detection is also needed to know where in ram we should load the kernel and offsets for initramfs and dtb to be loaded. anaconda can tell us the filesystem and device that we are installing to, but depending on the exact way support is done in uboot we may need to put in different values, SCSI vs SATA vs USB etc we also need to ensure we use the right dtb file. for instance a pandaboard ES can use a pandaboard dtb but will be 1ghz vs the 1.2ghz its capable of. some systems like the highbank ones have the dtb in their uboot. while others need to load an external file. so as i see it we need a library that anaconda can import and use to work out the right values for the system we are installing to. probably the library should write out the uboot template and run mkconfig on it. we could then reuse the library in a tool to say setup a boot sdcard to run the installer on a system. we have an issue where it is really not possible to make the equivilent of a boot.iso that will be bootable everywhere. I think we should take this up to the cross distro list at linaro and ideally have the distros work on a database at the least of platforms and the values and types needed. if not the whole library that can be used in different places to set things up. this is only needed for 32 bit arm, 64 bit will have UEFI, ACPI and grub2. potentially we also want to consider if we can implement http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec since we need to implement something anyway. Dennis

1 0

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

[isomd5sum][patch] Clang support
by Mykola Marzhan 26 Feb '13

26 Feb '13

please commit attached patch. It is required for add Clang compiler supporting. -- Mykola Marzhan PortaOne, Inc., Release Engineer delgod(a)portaone.com Tel: +1-866-SIP VOIP (+1 866 747 86 47) ext. 7159 PortaOne - VoIP Solutions Company Visit our Website: http://www.portaone.com

2 1

Storage events
by Jan Safranek 25 Feb '13

25 Feb '13

Hello all, I've talked to David Lehman (Blivet devel) how OpenLMI can report various storage events to applications. Currently, Blivet does not consume any events from udev and it would be rather difficult to implement it - Blivet is a library and receiving events means it must have some sort of listening thread with a main loop. 1: http://pyudev.readthedocs.org/en/latest/ So, what events OpenLMI wants to report to applications (and what info it wants) [source of the event]: - device appeared/disappeared [udev] - device was changed (*what* changed - e.g. size, fs on it, RAID level, ...) [udev] - mount appeared/disappeared [/proc/mounts] - mount changed (list of changed options) [/proc/mounts] - RAID events - man mdamd, look for "MONITOR MODE". There might be netlink/inotify/dbus events for that. - LVM events (snapshot/thin LV/VG is running out of space; with configurable threshold) [none at the moment] As written on [2], select or poll on /proc/mounts or /proc/self/mountinfo can be used to get mounting events. 2: http://karelzak.blogspot.cz/2011/12/monitor-list-of-currently-mounted.html Question is, how Blivet and OpenLMI cooperate to generate these events. Option 1: OpenLMI listens for udev and mount and mdadm events (in C, not in Python). When an event occurs, it re-creates Blivet's device tree and compares old and new trees manually on its own. Benefit of this solution is that Blivet (Python) does not need to be in memory for the whole time. This would require some wrapping between CIMOM and OpenLMI, but I think that's doable. Option 2: OpenLMI tells Blivet to wait for events. When event occurs, Blivet calls OpenLMI callback. Add/remove events are simple, just tell OpenLMI what appeared/disappeared. Changes are more complex, but IMHO it might be enough to call the callback with old StorageDevice and new StorageDevice and we'll check what's changed. This solution can be used by more applications on top of Blivet, but it requires Blivet to run a main loop in a thread and be in memory for the whole time. Option 1.5: OpenLMI listens for the udev, mount and mdadm events (in C, not in Python), but passes them in some 'raw' form to Blivet. Blivet then check what's going on and calls OpenLMI callback as in Option 2. We don't need to have Blivet in memory for the whole time, but we need it to be possible to store Blivet state to a file and reload it when requested. Of course, we expect incremental development, let's start with udev first and gradually integrate all other sources of events. I personally vote for option 2, not because it's more work for Blivet and less for OpenLMI, but if Blivet is going to be generic storage library, this is one of core functionality. If option 2 show too resource-heavy, we might try to go for 1.5. Jan

1 0

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

Idea for changing RAID selection UI
by Máirín Duffy 19 Feb '13

19 Feb '13

Hi folks, Stephanie and I have been doing some thinking about improving the RAID selection UI in Anaconda. Stephanie put together a couple of mockups to show one of our ideas - basically, by default we'd allow users to pick RAID via 'features' the way the UI is in F18, but we'd provide an optional radio button you could select to indicate a specific RAID level if you have a target RAID # you need to go for. Her mockups are here: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/RAID%20doom/RAID-… http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/RAID%20doom/RAID-… Do you think something like this would be a workable improvement to the UI? ~m

8 7

Request for thread info
by Nandan Bhat 19 Feb '13

19 Feb '13

Hi, I was participating in a discussion at the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=875433 . Well, it was termed NOTABUG, so I want to find out some info about it. Can anyone point me in the direction (link/date) when the discussion about locking down DVD install options for desktop environments got discussed in this mailing list? Alternatively, if this is not the right place for such stuff, please be kind to point me over to the correct list/forum. Thanks, Nandan

2 2

Mock-ups
by Daniel Davies 18 Feb '13

18 Feb '13

Hi, I've recently installed Fedora 18. I think the new installer looks great and appreciated the hard work you've put into it. I've made some mock-ups with suggestions that maybe of interest. The mock-ups can be found at http://perceptionflux.blogspot.nl/ Any constructive feedback is welcome. Dan.

5 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 February 2013