Anaconda-devel July 2009

anaconda-devel@lists.fedoraproject.org

29 participants
100 discussions

RFC: writing kernel cmdline options to grub.conf for dracut
by Hans de Goede 02 Jul '09

02 Jul '09

Hi, This morning I've been talking to Harald Hoyer about what sort of commandline options dracut will be needing to find the / filesystem beside root=UUID=1234567890 . In most cases (normal disks, dmraid, mdraid, lvm, dmcrypt) root=UUID=1234567890 should suffice. However in certain cases for example dracut will need additional info to find the disks. We've come to the following plan for iscsi targets: 1) Extend the dhcp_root dhcp variable iscsi syntax to be able include a username password, so: iscsi:192.168.50.2::::iqn.2009-06.dracut:target66 Can become: iscsi:user:pass@192.168.50.2::::iqn.2009-06.dracut:target66 Or: iscsi:user:pass:reverse_user:reverse_pass@192.168.50.2::::iqn.2009-06.dracut:target66 2) Pass root-path=iscsi:... on the kernel cmdline, for each needed iscsi target, so if necessary this will be passed multiple times, dracut will be modified to be able handle multiple root-path arguments being passed in 3) chmod /proc/cmdline 400, so that it cannot be read by ordinary users, plugging the passwork leak problem Now the remaining question is how to implement the adding of the needed cmdline options to grub.conf. For the iscsi case (and atleast fcoe will be similar) I see the following 2 options, both of which are feasible: 1) Add code to iscsi.py to get the needed cmdline options 2) Add a dracutCmdlineOptions property to all Device classes, which will return the needed options (if any) to make the device in question available inside dracut. One of the issues here is that onlining an iscsi target, may get us multiple disks as the target may have multiple LUN's. If more then one LUN of the same target is needed we might end up with having the same root-path=iscsi:... option twice on the cmdline, filtering this will be is easy though so this is not really an issue. Looking at this from the iscsi pov, doing this from iscsi.py is easier, as that already has a list of targets instead of a list of disks (so LUN's) as the rest of the storage code has. Looking at this from the pov of the rest of the code it might be cleaner in the long run to make this a device property though. So I'm not sure what to do, advice is / ideas are very welcome ? Regards, Hans

3 3

RHEL-5 patch to fix #448006
by David Cantrell 02 Jul '09

02 Jul '09

Regression introduced by me for the fix for #432011, this patch makes sure we grab the bootfile from the DHCP response. Tested locally using a RHEL 5.3 tree. The 'ks' argument works with this patch in place. -- David Cantrell <dcantrell(a)redhat.com> Red Hat, Inc. / Honolulu, HI

2 4

[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

[PATCH - 497334] change the basic assumption about kickstart network
by Chris Lumens 01 Jul '09

01 Jul '09

These two patches change one of the basic operating assumptions about the network command in kickstart. Before: No "network" command implies dhcp Now: No "network" command implies stop and ask in stage1 This brings the network command in line with how everything else in kickstart, and also gets rid of the obnoxious and short lived --bootproto=query, though it will still have to be recognized for compatibility reasons. - Chris

2 3

[PATCH] Set focus on hostname entry in network UI screen (#494135)
by Radek Vykydal 01 Jul '09

01 Jul '09

--- iw/network_gui.py | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/iw/network_gui.py b/iw/network_gui.py index 9f5ced7..ce2c879 100644 --- a/iw/network_gui.py +++ b/iw/network_gui.py @@ -44,13 +44,16 @@ class NetworkWindow(InstallWindow): self.hostnameEntry.set_text(self.hostname) self.hostnameEntry.connect("activate", lambda w: self.ics.setGrabNext(1)) - self.hostnameEntry.grab_focus() + self.hostnameEntry.connect("map-event", self.setFocus) # load the icon gui.readImageFromFile("network.png", image=self.icon) return self.align + def setFocus(self, area, data): + self.hostnameEntry.grab_focus() + def hostnameError(self): self.hostnameEntry.grab_focus() raise gui.StayOnScreen -- 1.6.0.6

2 1

[PATCH] two patches for rawhide, the second depends on the first
by Radek Vykydal 01 Jul '09

01 Jul '09

The 2/2 patch is "TAKE III", this one depends on the 1/2 patch.

1 5

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

Features/YumLangpackPlugin and anaconda consequences
by Bill Nottingham 01 Jul '09

01 Jul '09

Crrently, in anaconda and yum, we install language specific addons via conditional packages in comps. It's generally agreed that this sucks as an intereface, but it's what we have. There is a proposal to move this to a yum plugin for Fedora 12. Whenever a package has language-specific extensions (such as 'openoffice.org-core'; these packages would be described in some metadata), the corresponding language pack (determined via %_install_langs, most likely) would be installed. However, this has two conseqences for anaconda. 1) Plugins Anaconda doesn't currently enable them. We would want this to work in some way in anaconda, which would require enabling at least this plugin. How possible is this? 2) The actual installation experience Right now, if you pick an install language, that language group is automatically enabled. Additional languages are offered via their comps groups through customized package selection. However, that has two issues: - We never show these groups if there are only conditional packages in it, at least according to various bugs I've seen filed (oops) - If we're doing this via a plugin only, how can we better set our install languages if these comps groups don't exist? For the latter question, we may want to run some ideas past design. Bill

4 4

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel July 2009