Anaconda-devel September 2011

anaconda-devel@lists.stg.fedoraproject.org

24 participants
81 discussions

[PATCH rhel5-branch] Initialize useIPv6 device setting (#713120)
by Radek Vykydal 03 Oct '11

03 Oct '11

We need to set the default (which is "yes") also in cases when network is not activated in loader and kickstart is not used (i.e. interactive DVD installs). --- network.py | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/network.py b/network.py index c840cde..fd168b1 100644 --- a/network.py +++ b/network.py @@ -280,6 +280,10 @@ class Network: for netdev in probedevs: device = netdev.device if device in self.netdevices.keys(): + + self.netdevices[device].set(("useIPv4", flags.useIPv4)) + self.netdevices[device].set(("useIPv6", flags.useIPv6)) + desc = netdev.desc if desc is not None and len(desc) > 0: self.netdevices[device].set(("desc", desc)) -- 1.7.4

2 2

firstaidkit-plugins?
by Will Woods 01 Oct '11

01 Oct '11

Right now the only firstaidkit plugin we install is 'grub'. It seems like 'passwd', 'key-recovery', 'mdadm-conf', and 'xserver' might also be useful, and they're like <10kb each, uncompressed. Which should we include, if any? -w

3 2

patch dump
by David Lehman 30 Sep '11

30 Sep '11

All are for f16-branch, but none for beta. Patch 4 seems to be a recurring issue. Apparently the last time someone worked on this they only had one disk in their test box. Patch 5 is also for rhel6-branch.

3 7

[PATCH] Add nfsiso: handling to parseNfsHostPathOpts
by Brian C. Lane 30 Sep '11

30 Sep '11

From: "Brian C. Lane" <bcl(a)redhat.com> This was causing the wrong url to be used when looking for RHUpdates/, updates.img and product.img on an nfs .iso install. NOTE: Tested along with fix for #741466 --- loader/nfsinstall.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/loader/nfsinstall.c b/loader/nfsinstall.c index d29e98a..f46e79e 100644 --- a/loader/nfsinstall.c +++ b/loader/nfsinstall.c @@ -123,12 +123,14 @@ static int nfsGetSetup(char ** hostptr, char ** dirptr, char ** optsptr) { /* Parse nfs: url and return its componenets * - * nfs[:options]:<server>:<path> + * (nfs|nfsiso)[:options]:<server>:<path> */ void parseNfsHostPathOpts(char *url, char **host, char **path, char **opts) { - /* Skip over the leading nfs: if present. */ + /* Skip over the leading nfs: or nfsiso: if present. */ if (!strncmp(url, "nfs:", 4)) url += 4; + else if (!strncmp(url, "nfsiso:", 7)) + url += 7; logMessage(DEBUGLVL, "parseNfsHostPathOpts url: |%s|", url); -- 1.7.6

2 1

Re: Fwd: Re: [f16-branch] Write human readable timezone information to /etc/timezone.
by Lennart Poettering 30 Sep '11

30 Sep '11

(Replying to a mailing list mail in a forwarding from Ales, sorry for that) On 06.09.2011 08:29, Ales Kozumplik wrote: > > > -------- Original Message -------- > Subject: Re: [f16-branch] Write human readable timezone information to > /etc/timezone. > Date: Wed, 31 Aug 2011 09:39:20 -0400 > From: David Cantrell <dcantrell(a)redhat.com> > Reply-To: Discussion of Development and Customization of the Red Hat > Linux Installer <anaconda-devel-list(a)redhat.com> > Organization: Red Hat > To: anaconda-devel-list(a)redhat.com > > On 08/31/2011 06:52 AM, Ales Kozumplik wrote: >> This is to unify this basic config file with other distros. systemd is >> made to >> maintain it in sync with /etc/localtime. > > If systemd maintains the symlink, why can't it create it when it doesn't > exist? Systemd seems to be treating /etc/localtime as authoritative in > this case. Symlink? There is no symlink. The new file /etc/timezone is a one line text file with the time zone name. It has been used like this on Debian, Ubuntu, Gentoo. And that for a very good reason: because otherwise getting a textual description for the current zone is really messy, since you need to iterate through /usr/share/zoneinfo and look for the file that is identical to /etc/localtime. That is slow, fragile and massively IO intensive. systemd whenever it changes /etc/localtime will also write /etc/timezone to the right value. All I am asking here is that anaconda as the initial tool that writes /etc/localtime does the same. >> f = open(instPath + "/etc/adjtime", "w") >> f.write(lines[0]) >> f.write(lines[1]) > > The problem I have with these sorts of patches are that anaconda now > owns the initial creation of this symlink. What happens when the > symlink has to move, change, or otherwise be modified in the future? I > guarantee you that the group making that decision will not communicate > it with us and we will deal with it in a reactive manner. There is no symlink. And it won't move. We are just basically copying here what Debian/Ubuntu/Gentoo have been doing for ages for a very good reason. They didn't have to change the file in the last 10y or so, and I see very little for us to make any similar changes. This isn't really anything new. It's just following an established de-facto standard where we were basically the only ones who didn't follow it. This is very unlikely to change anytime soon. And even in the worst case: since /etc/localtime is authoritative the effect of /etc/localtime and /etc/timezone being out of sync is minimal. Configuration frontends might default to the wrong setting, but that's it. > So I always ask myself if anaconda really needs to own the creation of > this symlink or if it can be placed in another component? It's no symlink. And the thing is that nobody else can fill in that file efficiently since it requires iterating through /usr/share/zoneinfo. It must be the tool which writes /etc/localtime that also writes /etc/timezone. Since it has the right information anyway. > The bug indicates that systemd is pushing for common files like this to > avoid having applications scour /usr/share/zoneinfo to get a human > readable name for /etc/localtime. Why not have systemd just do that at > boot up? It's an expensive IO-intensive operation, and we want to boot fast... Doing that at every boot is ridiculous. It's a trivial operation if everybody who writes /etc/localtime also writes /etc/timezone at the same time. Most tools which are portable to other distros do this already anyway. Anaconda currently doesn't, but it would be great if it did. Like the Debian installer does, or the Ubuntu one. Note that a major reason to do this change is compatibility with other distros, there's no need here that we cook our own soup, and distinguish ourselves from Debian/Ubuntu/Gentoo. It's more efficient, more descriptive to write /etc/timezone whenever you write /etc/localtime. It's also helps unifying the various Linux platforms out there. > Will users know to update /etc/timezone when they update > /etc/localtime? I am pretty sure the fewest people change that file manually, and instead use some kind of tool for it. Since /etc/timezone is a de-facto standard on many Linux distros most of those tools already know how to write those files. In particular, since the Ubuntu/Debian userbase is bigger then ours it will be easier and more obvious to understand this, especially for newcomers. And again, even if the two files get out of sync, the effect won't be that bad. > Or will some users think they can change /etc/timezone > to change the timezone and leave /etc/localtime alone and then wonder > why things don't work? Things will work, since only /etc/localtime is authoritative and is used by the glibc. if /etc/timezone is out of sync the worst that happens is that for example GNOME's tz configuration UI shows you out of date timezone info. > Perhaps system-config-date could offer a Python > library, C library, and command line tool to look up /etc/localtime and > print out the human-readable name? Nah. I am sorry. We don't need a library for this, especially since that would be used on Fedora only and nowhere else. > In short, I do not think this is a thing anaconda should own. It's nothing anaconda should "own". it's just a file that anaconda should write, when writing /etc/localtime. The file is currently ghosted and owned by systemd, but could be moved to setup.rpm or filesystemd.rpm, too, doesn't really matter. So, please, here again the reasons why we want this: - It makes querying the local timezone for presentation in configuration tools easy and efficient at minimal IO. The previous way to determine it was highly IO intensive and ugly to work for. - It's an accepted de-facto standard used on many other distros. Unifies the Linux platforms. - Already implemented in many tools that can set the timezone. Major missing tool is basically Anaconda. - Keeps our stack simple, since we need no complex algorithms, libraries, or other complexities that need maintainance. Please don't work against the unification of Linux. Lennart

5 9

Question about Anaconda graphics for F16
by Máirín Duffy 30 Sep '11

30 Sep '11

Hi, So for the past couple of releases or so the Anaconda GUI (and Firstboot as well, I'm pretty sure) display at full screen size rather than stay limited to 800x600 px as they used to be. The gradient banner at the top of Anaconda looks odd because of this; it's not long enough to cover the full width of the window. Firstboot at least stretches out the left banner it has although this looks a bit pixelated (at least when I'm running it in debug mode now it does. :) ) I am wondering what options are possible then to get Anaconda's banner looking nice for F16. I poked around the anaconda.glade file; I think we have a couple of options but I'm not sure how to do one of them: OPTION #1: no gradient, left-align Fedora logo This would basically look the same as it did pre-full screen mode, but without the gradient. The glade file would have to be changed; the 'X Align' value on the image in the glade file should be changed from 0.5 to 0, and the 'X Pad' value should be set to something like '10'. OPTION #2: keep the gradient, but stretch it full screen. I don't know how to do this, but I know it's possible... create a container 105 px tall, and set the gradient as its background image with 'repeat' set. Then, place the Fedora logo in that container, aligned as explained above. I found some references to setting a widget/container background image in GTK+ here: http://mail.gnome.org/archives/gtk-list/2007-April/msg00045.html http://www.scribd.com/doc/45906237/Pygtk2-Tut What do you think? ~m

4 8

keep output constant
by Hongqing Yang 30 Sep '11

30 Sep '11

Hi, Anaconda Developer Team, I found on the F16 Alpha release, after the media check, there is output 'Running anaconda 16.14.6, the Fedora system installer - please wait', but in Beta RC1 release, it is removed. I use the output as the installation step label for AutoQA, it would better if we can keep it constant, or the auto install test will not work. Can you tell me if you propose to remove it definitely or not? So I can find other label for the install step. Thanks. Hongqing Fedora QE

2 3

new UI things to do
by Chris Lumens 30 Sep '11

30 Sep '11

If you're looking for something new and interesting to do, check out my list of new UI work items: https://fedoraproject.org/wiki/Anaconda/Work_List The screen numbers are references to the mockups mizmo has posted a couple times. I think I covered just about everything else in the wiki page. There's no time limit on this, and I'll post other stuff as I think we're ready to start tackling it. If you have any questions, please let me know. I'm excited to see what everyone comes up with! - Chris

4 4

[PATCH] Don't pull in grub2 or efibootmgr by default.
by Peter Jones 29 Sep '11

29 Sep '11

Anaconda selects these if we're on an appropriate system, so don't pull them in by default. --- comps-f16.xml.in | 2 -- comps-f17.xml.in | 2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/comps-f16.xml.in b/comps-f16.xml.in index be87539..819a907 100644 --- a/comps-f16.xml.in +++ b/comps-f16.xml.in @@ -756,8 +756,6 @@ <packagereq type="mandatory">util-linux</packagereq> <packagereq type="mandatory">vim-minimal</packagereq> <packagereq type="mandatory">yum</packagereq> - <packagereq type="default">efibootmgr</packagereq> - <packagereq type="default">grub2</packagereq> <packagereq type="default">ppc64-utils</packagereq> <packagereq type="default">s390utils</packagereq> <packagereq type="default">sendmail</packagereq> diff --git a/comps-f17.xml.in b/comps-f17.xml.in index 267fafa..fe3fa63 100644 --- a/comps-f17.xml.in +++ b/comps-f17.xml.in @@ -691,8 +691,6 @@ <packagereq type="mandatory">util-linux</packagereq> <packagereq type="mandatory">vim-minimal</packagereq> <packagereq type="mandatory">yum</packagereq> - <packagereq type="default">efibootmgr</packagereq> - <packagereq type="default">grub2</packagereq> <packagereq type="default">ppc64-utils</packagereq> <packagereq type="default">s390utils</packagereq> <packagereq type="default">sendmail</packagereq> -- 1.7.6

2 4

[PATCH] Don't pull in grub2 or efibootmgr by default.
by Peter Jones 29 Sep '11

29 Sep '11

Anaconda selects these if we're on an appropriate system, so don't pull them in by default. --- comps-f16.xml.in | 5 +++-- comps-f17.xml.in | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/comps-f16.xml.in b/comps-f16.xml.in index be87539..a29daae 100644 --- a/comps-f16.xml.in +++ b/comps-f16.xml.in @@ -756,14 +756,15 @@ <packagereq type="mandatory">util-linux</packagereq> <packagereq type="mandatory">vim-minimal</packagereq> <packagereq type="mandatory">yum</packagereq> - <packagereq type="default">efibootmgr</packagereq> - <packagereq type="default">grub2</packagereq> <packagereq type="default">ppc64-utils</packagereq> <packagereq type="default">s390utils</packagereq> <packagereq type="default">sendmail</packagereq> <packagereq type="default">silo</packagereq> <packagereq type="default">systemd</packagereq> <packagereq type="default">yaboot</packagereq> + <packagereq type="optional">efibootmgr</packagereq> + <packagereq type="optional">grub2</packagereq> + <packagereq type="optional">grub</packagereq> </packagelist> </group> <!-- diff --git a/comps-f17.xml.in b/comps-f17.xml.in index 267fafa..eb5b815 100644 --- a/comps-f17.xml.in +++ b/comps-f17.xml.in @@ -691,14 +691,15 @@ <packagereq type="mandatory">util-linux</packagereq> <packagereq type="mandatory">vim-minimal</packagereq> <packagereq type="mandatory">yum</packagereq> - <packagereq type="default">efibootmgr</packagereq> - <packagereq type="default">grub2</packagereq> <packagereq type="default">ppc64-utils</packagereq> <packagereq type="default">s390utils</packagereq> <packagereq type="default">sendmail</packagereq> <packagereq type="default">silo</packagereq> <packagereq type="default">systemd</packagereq> <packagereq type="default">yaboot</packagereq> + <packagereq type="optional">efibootmgr</packagereq> + <packagereq type="optional">grub2</packagereq> + <packagereq type="optional">grub</packagereq> </packagelist> </group> <!-- -- 1.7.6

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 September 2011