Anaconda-devel June 2009

anaconda-devel@lists.stg.fedoraproject.org

32 participants
83 discussions

[PATCH 1/2] Don't populate flags.cmdline with "True" values when no = is used.
by Peter Jones 12 Aug '09

12 Aug '09

Since all tests are either flags.cmdline.has_key() or "if flags.cmdline.get()", we want this to be None when there's no equals sign, rather than True. --- flags.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/flags.py b/flags.py index 8dbcc9f..d49b252 100644 --- a/flags.py +++ b/flags.py @@ -59,7 +59,7 @@ class Flags: (key, val) = i.split("=", 1) except: key = i - val = True + val = None cmdlineDict[key] = val -- 1.6.2.2

3 3

[PATCH] Do not go interactive if timezone in ks is not valid (#473647).
by Radek Vykydal 07 Aug '09

07 Aug '09

Handle invalid timezones in ks the same way as in RHEL 5.4: in case that the timezone is invalid, the system time of install environment will be set correctly if it is in tzdata package, and even if it is not there the ks install will proceed. This will prevent possible breaking of installs with kickstarts working in older versions of RHEL. The question may be if we can/want to broaden valid timezones to all those present in tzdata package officialy (document it). Complete tzdata package is part of stage2 in Fedora and will be in RHEL 5.4. --- kickstart.py | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/kickstart.py b/kickstart.py index 474ecec..ae6ae3a 100644 --- a/kickstart.py +++ b/kickstart.py @@ -881,8 +881,7 @@ class Timezone(commands.timezone.FC6_Timezone): tab = zonetab.ZoneTab() if self.timezone not in (entry.tz.replace(' ','_') for entry in tab.getEntries()): - log.warning("Timezone %s set in kickstart is not valid, will ask" % (self.timezone,)) - return retval + log.warning("Timezone %s set in kickstart is not valid." % (self.timezone,)) self.handler.id.timezone.setTimezoneInfo(self.timezone, self.isUtc) self.handler.skipSteps.append("timezone") -- 1.5.4.3

2 1

Installer device Filtering...
by Joel Granados 07 Jul '09

07 Jul '09

Hello list. There was a discussion in irc about device filtering. I just wanted to summarize and post what was discussed so we can maybe get some valuable insight from the mailing list. This is more like an irc dump than a summary. But I hope it shows some of the topics that should/could be discussed * What information to give to the filter? This is related to the UI. And this was the reason to begin the discussion. - Give a regular expression that identifies the devices - Specify with a checkbox if you want anaconda to use the regular expression. - Specify what that regular expression should do (Ignore or Include) * On what would those regular expressions operate? - canonicalized path of the device link under /sys/block. - []$ readlink -f /sys/block/sda/device /sys/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0 - /dev/disk/by-path version is also possible. Could be useful. * Why not have the possibility to refresh? (Refresh would work with the information contained in the kernel.) - The user tweaks the scanning list and hits refresh. - User does this until he/she is satisfied with the device list. * Three possible scanning stages where identified. Each of these might be controlled by the filter. 1. Kernel scan 2. udev scan 3. devicetree.py:scan * We actually want to be able to tell the kernel not to scan certain LUN's. * Wish people would learn how to configure fibrechannel switch acl's so we would only see the lun's they actually want us to touch. Would it be a good idea to document the configuration setup that anaconda expects? * How would udev filters aid us with the overall filtering. Regards. -- Joel Andres Granados Brno, Czech Republic, Red Hat.

6 5

We need to start thinking about writing kernel cmdline options to grub.conf for dracut
by Hans de Goede 05 Jul '09

05 Jul '09

Hi All, When we switch to dracut we will need to specify certain kernel commandline options to dracut. For example when / is on iscsi dracut will need information for configuring the nic and about the iscsi target present on the kernel cmdline. The easiest way to handle this would be to add a new attribute to all devices which returns a list of kernel cmdline options to add to bring up that device (which will be empty in most cases). The problem here is that we can need (for example) multiple iscsi disks, and the question then becomes how to merge the cmdlines returned from the various devices. Harald I've included you in the CC, because I think this is something which dracut cannot handle at all atm. The parameters like iscsi_target_name, etc. All only take one value AFAIK, but what then if we need to bring up 2 different iscsi targets, for example for doing a mirror on 2 different iscsi disks ? I'm thinking that it would be better to have an iscsi= option, which will then contain the rootdev= iscsi syntax from dhcp (so all info for one target in one string) and allow having this option multiple times, does that sound like a plan ? Regards, Hans

4 5

[PATCH] Rework tracking of devices containing install media (#497087)
by David Lehman 02 Jul '09

02 Jul '09

This set of patches changes the way we track devices containing installation media. It is a two-stage approach: First, we save the device specifications exactly as provided to us. Second, when populating the device tree, we set the protected attribute of devices matching the provided specs. This frees us from worrying about devices being renamed since the attribute indicating that a device is protected is part of the device instance itself.

3 9

RFC: proposal for handling isw dmraid -> mdraid upgrade path
by Hans de Goede 01 Jul '09

01 Jul '09

Hi, I've been thinking about $SUBJECT lately, and I would like to propose the following way to handle this: 1) Make the use of mdraid or dmraid for BIOS-raid supported by both configurable both in anaconda (it already is) and in the installed OS (so in relevant udev rules and / or in rc.sysinit). anaconda will have a cmdline option to override the defaults, and the installed system will have a /etc/sysconfig/biosraid file, with a single setting: PREFERRED_BIOSRAID_HANDLER Which can be either dmraid or mdraid 2) On a fresh install anaconda will use mdraid and will write "PREFERRED_BIOSRAID_HANDLER=mdraid" to /etc/sysconfig/biosraid (unless forced to use dmraid through the command line) 3) On an update anaconda will look for /etc/sysconfig/biosraid, and use what ever is there, if the file does not exist (as it will not an an upgrade from F-11), it will use dmraid as we did in previous releases and write "PREFERRED_BIOSRAID_HANDLER=dmraid" to /etc/sysconfig/biosraid, so that future upgrades will still use dmraid. This will result in an it just works experience for users, and offers the ability to keep using dmraid for BIOS-raid supported by path, which is something several people have indicated they want. The only hole I can poke into this is yum update's from F-11, but we can document what to do on the yum upgrade wiki page, which people doing yum upgrade's should always read. Regards, Hans

3 7

More on the GUI (post FUDCon)
by Joel Granados 01 Jul '09

01 Jul '09

Hey list. Met with Mo at FUDCon and got lots of great ideas. This mail is intended to share some of these. 1. First of all she gave me a cool reference that can be used for general Human Interface design purposes. http://library.gnome.org/devel/hig-book/stable/. This is the most recent one I found, I believe its from 2008, if there is a more recent one, pls scream. 2. Help information. This refers to text that explains stuff that is not be trivial to understand. Instead of doing a help mechanism we could create a small explanation label, where needed, that goes under the concept that needs explaining. Much like http://library.gnome.org/misc/release-notes/2.26/figures/rnusers.brasero.pn… or http://library.gnome.org/misc/release-notes/2.26/figures/rnusers.epiphany.p… where the buttons have the name and the explanation in some other size and are slightly clear. 3. Have simplified device names. To have "sda" instead of "/dev/sda" and we would place the whole path "/dev/sda" as a small comment on the bottom of the device name. I'm guessing this would ease the user experience with dmraid type devices. 4. Use verbs for the actions. We have already been discussing this in the list. 5. Use Gig for the sizes. I had missed this in previous posts. But it be a good idea to have the size in Gb after 999 Mb. We can have a function that returns the show-able string. 6. Merge tree and bar view (This is my personal favorite, And I'll probably include it in a glade file in future posts. :). To have the bar information on the tree view. It would be on the far right and it would just have minimal information as most of it is contained in the tree view. I have to give Mo all the credit for this one :) 7. Put the type of installation (where we select "use entire drive", "Replace existing Linux system"...) in a separate window with additional comments on the options. This has two advantages, IMO, 1. We give the user more info so he/she can make an informed decision. 2. We don't show the encrypted check box when it is not needed (less confusion for the user). I still don't know exactly where to put the advanced configuration button in this case though. 8. Giving the user the possibility to select more than one device to shrink by using a checkbox instead of a drop down menu. Don't really know how much of a good idea this is, since I don't really know how that is coded, but its worth considering IMO. 9. The location of the action buttons would be better on the bottom left. This goes better with the look and feel of other gnome applications. So we would have the tree view, then the action buttons and then the "continue" & "Back" buttons. 10. We should pop up a window with all the "create" possibilities [1] for the customize partition "create" button. They would be handled with a comboboxe and would have a little explanation beneath the choice type. The user would select what he/she wants and a screan that creates the device would pop up. Mo: If I am forgetting something, pls chime in. Finally, considering that this will not be a complete re-write of the GUI for the storage section. I will probably start cleaning up the GUI files to get a better modularization and to easily move things around for the changes that we are planning. As always, suggestions are very much appreciated. [1] -> "LVM - physical volume", "LVM - Logical Volume" .... -- Joel Andres Granados Brno, Czech Republic, Red Hat.

4 6

[PATCH] Two unrelated patches for anaconda master
by David Lehman 30 Jun '09

30 Jun '09

2 3

RFC: howto handle upgrades of zfcp / iscsi
by Hans de Goede 30 Jun '09

30 Jun '09

Hi, This proposal is mainly meant for 5.5, for F-12 this will hopefully be handled from / to gether with the device filtering. I've been discussing $SUBJECT with some IBM people at Fudcon Berlin, and we came up with the following: Add an "Storage setup" screen between the welcome and the choose wether you want to install or upgrade screen. This screen will show a list of disks (as shown in auto_part.py but then without the checkboxes) and an "add storage" button, which will pop up the advanced storage dialog. This screen will be skipped by default on all archs except s390, as there this is only an issue when booting from non ibft iscsi, which is a rather unlikely scenario and it will be a too scary screen for desktop users or atleast unnecessary). On these archs there will be a cmdline option ("advancedstorage") to not skip the screen. Note that one of the reasons to make this default not skipped on is because we cannot use a cmdline option there, the other reason is that zfcp is quite common on s390, so it makes sense to always offer the ability to add zfcp disks before searching for installs to upgrade. This way: 1) Our normal installer flow is preserved (except on s390) 2) On s390 one will be able to upgrade installs on zfcp disks 3) On non s390 one will be able to upgrade non ibft installs, albeit this needs a cmdline option. Regards, Hans

2 1

Patchset to remove rhpl usage
by Jeremy Katz 30 Jun '09

30 Jun '09

Here's a set of patches to stop using rhpl in anaconda for everything *except* for keyboard models. We need to figure out what to do there, still. But this is a step in the right direction Jeremy

2 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel June 2009