Anaconda-devel March 2013

anaconda-devel@lists.stg.fedoraproject.org

16 participants
9 discussions

Minimum and recommended system requirements for Fedora
by Pete Travis 01 Apr '13

01 Apr '13

Hey anaconda riders, I've been trying to figure out the minimum system requirements for Fedora - basic stuff like CPU, memory, storage - and I don't know where to look. As I understand it, anaconda can require more memory than the final running system, so I thought I'd start here ( I did notice this improved a lot with the last release, nice work!) Anything you can do to answer the question or point me in the right direction, would be a big help. I made a half-hearted effort to find a source for it when preparing the Release Notes for F18, had no success, and so shipped release notes without the information. I'd rather not do that again, and I'm not comfortable coming up with the figures independently. Thanks, --Pete

5 10

F18 bug, bootloader install failed
by Chris Murphy 30 Mar '13

30 Mar '13

https://bugzilla.redhat.com/show_bug.cgi?id=895644 This has three separate causes, and abrt has made it a bit messy so I wonder if it's not going to get the attention it probably needs. Should new bugs be filed, and linked as clones of this one? 1. The originally reported case, I think the installation target is a USB stick that contains a dd'd Fedora 18 ISO. grub2-install complains about multiple partition schemes and won't proceed. This makes sense since the ISO's contain multiple partition maps, but I'm unable to reproduce, instead I get the crash in bug 895659. Maybe it's a parted bug, if it's not cleaning up the partition maps? Or, since the only partition must be deleted (reclaimed), anaconda could use wipefs on the whole device, to better prepare it. 2. Custom partitioning multiple disk installs, GPT scheme. If one of the disks doesn't have BIOS Boot, grub2-install fails to install and a crash is triggered. My argument is that EFI System and BIOS Boot partitions are system boot domain, not user domain, therefore anaconda should just create them - even when the user specifies custom partitioning. The knowledge to do this manually is esoteric, and further it's non-obvious whether the disk partition scheme is MBR or GPT so the user isn't in a good position to do this. File against 18, or as RFE for rawhide? 3. If the installation target is a drive with a 61 sector MBR gap (legacy start LBA 63 for 1st partitions), the core.img is too large to be embedded if LVM or btrfs are chosen device types. So grub2-install fails, then anaconda crashes. Arguably the legacy partition scheme is flawed, and waiting until the end of the installation to inform the user is bad UX. But at least a simple explanation would be better than no explanation, or a crash. Ideally, though, I think the installer should prequalify the drive, and tell the user in advance the boot loader will fail to install, and what the work arounds are: a.) Use Standard Partition scheme, instead of LVM or Btrfs. b.) Move/resize partition 1 so it starts on LBA 2048, then re-run the installer. c.) After Fedora installation, manually install boot loader to the /boot partition using grub2-install --force. File against 18, or as RFE for rawhide? Chris Murphy

2 5

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

python-meh and bug in Gtk
by Vratislav Podzimek 28 Mar '13

28 Mar '13

You may have hit the bug in Gtk when python-meh's window with the exception frozen when it was scrolled. This seems to be fixed in newer builds of Gtk (tested with a compose I made for it). -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

1 0

Major criteria re-write / re-design proposal: Beta draft
by Adam Williamson 14 Mar '13

14 Mar '13

Hey, folks. CCing anaconda list on this one due to the changes to the partitioning requirements (see below) - please send replies to test@, though, to avoid a thread fork. Further to my previous mail - https://lists.fedoraproject.org/pipermail/test/2013-March/114198.html - I've now got a first draft of the Beta criteria, along the lines of the Alpha draft in that mail. Here it is: https://fedoraproject.org/wiki/User:Adamwill/Draft_beta_criteria_sandbox I did much the same as the Alpha - tried to simplify the main text as much as possible, and use hidden paragraphs for legalistic details. I did not yet add the References sections. Oh, I should also note that one thing I mean to add to the References for all three milestones is a link for each criterion to the test case that enforces it. We'll also now be able to do links from the test cases to the criteria they enforce, so the two will be much more clearly tied together. There isn't much significant change to the wording in this Beta draft, somewhat less than there was in Alpha. Mostly just places I found I could rewrite things without losing any meaning. The exception is that I did the partitioning criteria rather differently, as we found quite quickly in the F18 cycle that we were unhappy with the first attempt at re-drafting the partitioning criteria. I decided to go with one set of criteria for guided partitioning and one for custom, explicitly written as such (it turned out we did not enforce enough requirements on guided partitioning, the way we had it written before). I decided to try and be less concise for this specific case, and write out the requirements more comprehensively. I also decided on balance this is a case where we shouldn't try to be too 'generic' as it just winds up being too vague - we had "most commonly-used filesystem types" before, which is so vague you could drive any kind of bus through it. So I figured we should just go ahead and specify the exact storage types we support, and adjust the list as time goes on. I think the actual requirements I came up with accurately reflect the consensus among QA and anaconda team about what we should realistically support at Beta. Notably I left out anything about resizing partitions and anything about re-using existing containers; I figure those are more appropriate for Final. I also left out 'complex' configurations like LVM-on-RAID. As part of the partitioning revamp I tried to make the RAID requirements more sensible (previously it talked about 'creating' hardware and firmware RAID, which doesn't make any sense). Again, comments, suggested refinements etc welcome! Especially if anyone can think of a way to make any of the 'main' criteria wordings even shorter and clearer, that would always be a win. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

1 0

RAID UI redo
by Máirín Duffy 12 Mar '13

12 Mar '13

Hi folks, Stephanie, dlehman, and I worked on a redesign of the RAID UI in Anaconda with Doug Ledford's help. I did a blog post sort of documenting the thought process and walking through the latest mock-ups. Would you mind taking a look and giving us your feedback? http://blog.linuxgrrl.com/2013/03/11/raid-re-do-for-anaconda/ Thanks :) ~m

7 8

Re: Boot Loader Spec
by H. Peter Anvin 12 Mar '13

12 Mar '13

On 03/12/2013 06:02 AM, Lennart Poettering wrote: > On Mon, 11.03.13 21:00, H. Peter Anvin (hpa(a)zytor.com) wrote: > >>> Note: $BOOT should be considered shared among all OS installations >>> of a system. Instead of maintaining one $BOOT per installed OS (as >>> /boot was traditionally handled), all installed OS share the same >>> place to drop in their boot-time configuration. >> >> This is really just begging on your knees for the various distros to >> stomp on each others bootloaders, or alternatively -- and just as badly >> -- not update the bootloaders at all. > > Well, the spec is pretty much exclusively about how to naturally not do > that (i.e. via drop-in snippets that are named uniquely). > I am talking about the *boot loader itself*. Who owns it? Now, the Grub people definitely have a history of promoting variants that make multibooting obnoxious, like installing itself in the MBR as opposed to a partition VBR; this is crazy for reliable multibooting, but crazy is the norm for Grub. >> It is way more robust to let each distribution have its /boot and worry >> about its own bootloader. > > Well, I like to fix problems where they are, instead of ignoring them. I > mean, you will never be able to fix that there's only one MBR and one > ESP where a boot loader can be in. We now define a scheme that allows > friendly OSes to cooperate when using it. You strategy appears more > about sticking the head in the sand and ignoring the problem entirely. It is not. It is based on many years of experience with how to make multibooting work well in real-life. -hpa

1 0

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

Re: Fwd: Re: Blivet mounting & fstab
by Karel Zak 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 have wanted this for a long time in anaconda, so I am happy to hear > it. I'd be willing to help with python bindings, but I would not want > to maintain them. I don't see a problem to maintain the bindig at util-linux source tree, but I have no time to implement it. I guess that for applications like anaconda it will be enough to have bindig for high-level things and for work with mount tables (fstab, /proc/self/mountinfo, ..). > > 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. > > Using a library gets us better error condition checking and reporting, I > would think. It certainly would have helped us a lot more back when we > had imount.c, but it's still a good idea. I'm going to extend the current library API to support fstab update (now the library supports parsing and only in-memory work with fstab entries). Karel -- Karel Zak <kzak(a)redhat.com> http://karelzak.blogspot.com

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