Anaconda-devel January 2009

anaconda-devel@lists.stg.fedoraproject.org

30 participants
108 discussions

[PATCH] Port of RHEL5 dlabel/autodd functionality for Fedora (#436951)
by Martin Sivak 19 Mar '09

19 Mar '09

Hi, the only think i do not like is the hardcoded RHEL name detection. Do we have any way how to pass arguments/flags in the .discinfo or some similarfile? and before you start asking questions, I already have some answers from discussion with Jeremy: > First of all, I still have strong reservations about this as I really > don't like the hard-coded, something called by this name getting used > and would much prefer it being explicitly specified... Me too, but we can't just drop the feature now, because Dell will scream.. again.. > We really need to stop polluting the flags namespace and come up with a > better way of passing this around. If we're going to do it, it could at > least be in the anaconda class instead Right now we do not have any other "information object" to store this kind of information > We use actual mount(8) now instead of calling mount(2). This means that > we can just do 'mount LABEL=foo /bar' and don't need any of the blkid > bits. We do, because there might be more driverdiscs with the same "oemdrv" label > As I said in the intro, I really don't want auto-mounting code -- we > should instead just use dd=LABEL=foo and let them pass that... I agree with you, but the problem is Dell, they think that passing arguments is "bad customer experience". We tried very hard to avoid it.. and the only compromise we were able to negotiate was that, this will be disabled by default in Fedora. >... at which point, this can just flow into being the regular driver disk code. The dlabel is now official feature in RHEL5, sorry but I'm not going through the discussion again now, I've spent half a year in trying to persuade Dell, that this is bad idea.. and if they do not see this in RHEL6, they will be at my throat again... >> - if self.anaconda.id.extraModules: >> + if self.anaconda.id.extraModules or flags.dlabel: It is the second RFE they have, sometimes their driverdisc doesn't contain any modules, so extraModules is empty, but the repository on the driverdisc is not. And they want to install some stuff using it. Again without any user interaction and without kickstart. We were at least able to tell them a way, which didn't need any code chnages, except this one (using comps.xml file in the repo). Look at #316631.

2 2

[PATCH] #430476 - docs update for driveorder ks command
by Martin Sivak 17 Mar '09

17 Mar '09

Hi, one small change to docs for #430476. Martin

3 2

Improved linuxrc.s390 (third try)
by David Cantrell 05 Mar '09

05 Mar '09

I'm gzipping the patch and attaching it because the list manager keeps telling me that the size is too large. It is, but, well, that's how it came from IBM. If I don't hear anything from people after a few days, I will take it that people are ok with this patch going in to rawhide. It's basically just a big rewrite to linuxrc.s390. There is also a new helper script for linuxrc.s390 that scans for devices on the system. And a one line patch to mk-images to make sure the new helper script is installed. Here's the text of the commit message: INTRODUCTION After booting the installation environment on System z, there are no local storage devices such as a CD/DVD drive available to install RHEL from. Hence, only installation from network sources is possible, which requires an initial setup of a network device to reach such an installation source. Due to the possibly large number of hardware network devices (hundreds) and the way they are configured in the hardware setup, Linux does not automatically detect and allocate all available network devices. There is need for a dialog from which the user can choose a sensible device configuration. The least common multiple of console devices on System z is limited in functionality -- it only supports line mode. The initial network setup also provides the ability for users to login over the network from a curses capable text terminal, to provide an X window display, or to use VNC in order to continue installation. DOWNSIDES OF CURRENT LINUXRC.S390 The initial network setup was done with a simple error-prone dialog without any possibility for the user to correct wrong input. On getting stuck, the only option for the user was a reboot, which of course means that he had to manually enter values all over again. The user was asked various questions and had to know exactly what answers to provide for a successful network setup. Linuxrc.s390 provided no guidance or support to simplify the choice of correct answers for the user. Configuration happened after the user had answered all questions which could lead to situations where configuration failed due to an earlier incorrect answer the user was not informed about. User feedback has shown, that these downsides can be an obstacle for a successful installation of RHEL on System z. IMPROVEMENTS OF NEW LINUXRC.S390 - dialog allows the user to correct single answers - dialog allows to restart configuration, providing previous answers as default values - dialog provides a sub shell for problem determination - cut-down question text prevents frequent scrolling on line mode terminal - explaining help text is shown for each question on user demand - automated decision which questions the user has to answer - semi-automatic configuration of network devices by providing a selection list of possible hardware configurations - manual configuration remains possible as before - sensible default answers are provided where possible - superfluous questions (NETWORK, BROADCAST) have been removed - answers by the user are strictly checked for syntax and semantics - whenever possible, each answer is used to do a configuration step and provide timely feedback to the user in case of an error - user transparent support of System z device blacklist (cio_ignore) for short boot times on systems with many (thousands) devices - basic support for installation from FCP-attached CD/DVD drive (our version of linuxrc.s390 is based on rhel5.3-snap1-20081029) - basic support for installation over IPv6 (full functionality would require further support in loader) - prints answers in a format which can directly be used for parm/conf file (as a complement to /root/anaconda-ks.cfg) - may serve as a specification on how to configure network devices on System z outside of an installer, e.g. in init scripts or configuration tools such as system-config-network Otherwise, our version is fully compatible with the current version including the processing of parm/conf files. We made sure that existing parm/conf files from users are processed with the same outcome as previously. Also the interactive mode asks the user questions in the same order as before, so users do not have to adapt to a completely new structure of the initial network configuration. Patch from Steffen Maier <MAIER(a)de.ibm.com>. -- David Cantrell <dcantrell(a)redhat.com> Red Hat / Honolulu, HI

4 10

[PATCHES] Fix indentation
by Jeroen van Meeuwen 18 Feb '09

18 Feb '09

Hi there, here's a couple of patches that fix tab usage vs. the use of spaces in some of the scripts that I needed to edit for the next patch. 58114b660e443a656bb37ea2265bdb98c7061e33 88d0046fd3a4889232b512cab7a2a62fbe9b523c c97837cf01ccb9af11a80fb49ec778e907c8e3a0 fbcbc55903973a43f6ff92beb1538095c1466269 from git://git.kanarip.com/anaconda , or, if mailman doesn't destroy the patches, the attached versions. Kind regards, Jeroen van Meeuwen -kanarip

6 10

[PATCH] 474484 - translate ext4dev -> ext4 in /etc/fstab
by Chris Lumens 16 Feb '09

16 Feb '09

For a brief time, we had ext4dev as the fs type for ext4. That means it'd end up in /etc/fstab. The attached patch makes readFstab understand this possibility and read it as ext4. - Chris diff --git a/fsset.py b/fsset.py index bb8b2a2..005c647 100644 --- a/fsset.py +++ b/fsset.py @@ -2873,6 +2873,12 @@ def readFstab (anaconda): fstotry = fstotry.split(",") else: fstotry = [ fstotry ] + + # ext4 used to be listed as ext4dev, so handle that possibility + for i in range(0, len(fstotry)): + if fstotry[i] == "ext4dev": + fstotry[i] = "ext4" + fsystem = None for fs in fstotry: # if we don't support mounting the filesystem, continue

2 1

autostep and encrypted root password
by Jeffrey Bastian 10 Feb '09

10 Feb '09

If kickstarting a RHEL 5.y system, and the kickstart file contains autostep rootpw --iscrypted $1$..... then the kickstart will stop and ask for the root password. If using a plain text root password, it autosteps through the root password screen as expected. See https://bugzilla.redhat.com/show_bug.cgi?id=471122#c4 for a patch for RHEL 5.3 Beta. Below is a similar patch for anaconda-11.4.1.56-1. Jeff --- kickstart.py.ORIG 2008-11-11 15:35:29.000000000 -0600 +++ kickstart.py 2008-11-11 15:39:42.000000000 -0600 @@ -1185,6 +1185,11 @@ dispatch.skipStep("installtype") dispatch.skipStep("bootdisk") + # if the root password is already encrypted, we cannot fill in + # the password field on the accounts screen, so skip it + if flags.autostep and self.id.rootPassword["isCrypted"]: + dispatch.skipStep("accounts") + dispatch.skipStep("bootdisk") dispatch.skipStep("betanag") dispatch.skipStep("regkey")

2 7

rawhide anaconda pychecker results
by Hans de Goede 02 Feb '09

02 Feb '09

Hi All, Can you all please take a look at these, and fix them (they are new compared to F-10) or let me know if they are new false positives, then I'll add them to the filter. iutil.py:395: Object (ppcType) has no attribute (items) kickstart.py:293: Object (kwargs) has no attribute (update) kickstart.py:298: Object (kwargs) has no attribute (update) livecd.py:258: Object (fsdict) has no attribute (keys) livecd.py:267: Object (fsdict) has no attribute (keys) packages.py:387: Object (publicBetas) has no attribute (items) partRequests.py:504: Format string argument count (0) doesn't match arguments (1) partRequests.py:685: Format string argument count (0) doesn't match arguments (1) partedUtils.py:549: Object (productUpgrades) has no attribute (has_key) yuminstall.py:587: Statement appears to have no effect yuminstall.py:590: Function (_getConfig) doesn't support **kwArgs Thanks, Hans

2 2

[PATCH] Make kickstart timezone value check consistent with system-config-date (#483094)
by Radek Vykydal 02 Feb '09

02 Feb '09

Use zonetab module for in place of zone.tab file. Zonetab (used by UI and s-c-date) adds some of Etc/* specifiers. --- kickstart.py | 13 ++++--------- 1 files changed, 4 insertions(+), 9 deletions(-) diff --git a/kickstart.py b/kickstart.py index f064740..eafd4d8 100644 --- a/kickstart.py +++ b/kickstart.py @@ -37,6 +37,7 @@ import warnings import upgrade import pykickstart.commands as commands import cryptodev +import zonetab from pykickstart.constants import * from pykickstart.errors import * from pykickstart.parser import * @@ -770,15 +771,9 @@ class Timezone(commands.timezone.FC6_Timezone): retval = commands.timezone.FC6_Timezone.parse(self, args) # check validity - f = open('/usr/share/zoneinfo/zone.tab', 'r') - for line in f: - line = line.strip() - if line[0] == '#': - continue - fields = line.split('\t') - if len(fields) > 2 and fields[2] == self.timezone: - break - else: + 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 -- 1.5.4.3

2 2

Re: [PATCH] Make pyblock compatible with new pyparted.
by Joel Granados 30 Jan '09

30 Jan '09

Hey David: After some consideration I have some questions ( comments bellow ), Guess I'm looking for some granularity. ----- "David Cantrell" <dcantrell(a)redhat.com> wrote: > > parted.IOException. The other error that could be raised is a I think an IO error is pretty serious and should be propagated to the caller. In this specific situation, when you are doing a raidSet.activate() and there is some IO error with the set, it will raise an exception. Anaconda or whoever is calling should decide what to do. > parted.DiskException, which currently only happens if you give > __init__() on parted.Disk something invalid. Guess this would only happen if parted.getDevice() went wrong, in which case the DeviceException would be received by the caller. My Questions What does pyparted do in these cases?: 1. when I try to open a device with no label (partition table). 2. when I try to open a device with a label but with no partitions. 3. when I try to open a device with a corrupt label. 4. when I try to get a disk from a device with corrupt label. 5. when I try to get a disk from a device valid label but with no partitions. 6. when I try to get a disk of a device with no label. 7. when I try to list partitions of a disk of a device with no label (if its possible to reach this situation) 8. when I try to list partitions of a valid disk with no partitions. 9. when I try to open a device from a device that is physically corrupt (IOerror) IMO this is what could be returned. 1,2,3: Should return a device, the only time a device should not be returned is when an IOerror occurs. 4,6: should not create the disk and should give me an exception (or some way of telling that it has no label, like a special state of the disk object). The no label situation should be ignored in pyblocks case and should not be propagated to caller. we might want to propagate the corrupt label, thats discussable though. 5: Should create a disk object. 7: This state, IMO, should not be reached. 8: should return something lik []. 9: IOerror exception. Pls note that I'm only referring to reading the partition table. Regards. -- Joel Andres Granados Red Hat / Brno Czech Republic

1 0

[PATCH] linker, rechter
by Jeroen van Meeuwen 30 Jan '09

30 Jan '09

Where commit c501b339a2a2d4f5f732655dde7eddc41c030ad7 tried to correct the location of the linker library in the boot image, but it only checked for ld-linux.so.2, not ld-linux-x86_64.so.2 with this patch, I try to fix that by testing if there is such a thing as ld-linux.so.2 or ld-linux-x86_64.so.2 in $LIBDIR, and then only continuing if both of these are not links (to what is now ld-2.9.so) already. Needless to say, these checks get executed for every instbin() call, so like a thousand times, and the next logical step would be to make that happen only once or twice. The problem I encountered was that ld-linux.so.2 turned out to be linked to ld-linux.so.2 itself. The check on whether ld-linux.so.2 is already a symlink fixes that problem, but the problem didn't arise on x86_64 to being with (since there is no ld-linux.so.2 in /lib64/). These are the only two arches I've been able to fix this for, but I can say that ppc/ppc64 does not have /lib{,64}/ld-linux*.so* files to begin with. (I should note that removing the patch in commit c501b339a2a2d4f5f732655dde7eddc41c030ad7 also solved my original problem) Also available as commit ce4eb694f2dee9701005ccee9edfb66358aa8c81 from remote git://git.kanarip.com/anaconda Please apply to master and f10-branch, if applied at all. Kind regards, Jeroen van Meeuwen -kanarip

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel January 2009