Anaconda-devel January 2007

anaconda-devel@lists.stg.fedoraproject.org

33 participants
24 discussions

a replacement for .discinfo?
by Will Woods 31 Jan '07

31 Jan '07

Hi folks, In the course of messing with various installer tools, I've ended up writing some python code that reads and writes an XML metadata file that is (basically) an easily-parsable superset of .discinfo. A quick overview of the concepts involved here, from the top down: A "compose" is, basically, an entire distribution - all the installable trees for all the various arches, plus iso sets, plus maybe some SRPMS and debuginfo packages that go along with them. I suppose I could rename this to "distro" but we've been using this terminology for so long that it's just stuck. A "tree" is a directory layout with all the packages and images you need to install from. An "isoset" is (surprise!) a full set of isos that make up the distribution. Okay, here's some examples. The tool that does the composing (pungi, distill, etc.) should create .compose.xml in the top-level of the compose dir. That file looks approximately like this: <compose id="rawhide-20070122" time="1169485348"> <debug arch="i386">development/i386/debug</debug> <debug arch="x86_64">development/x86_64/debug</debug> ... <source arch="i386">development/source/SRPMS</source> <source arch="x86_64">development/source/SRPMS</source> ... <tree arch="i386">development/i386/os</tree> <tree arch="x86_64">development/x86_64/os</tree> </compose> This defines the id of the compose (which should be unique for each compose, and would be nice if it was human-understandable like this one) and a timestamp that lets you know when it was created. Really this file just exists to tell point you to the actual contents of the compose, and where it all lives - there's debuginfo packages here, sources here, trees here, and so on. Later we should also have: <isoset arch="i386">development/i386/iso</isoset> Each of these items points to a directory where another xml file will have further information - a "tree" directory will contain a file named ".tree.xml", ".isoset.xml" for isosets, etc. So here's an example of tree.xml: <tree id="1169482851.57"> <compose>rawhide-20070122</compose> <family>Fedora Core 6.89</family> <version>6.89</version> <time>1169482851.57</time> <arch>i386</arch> <file type="kernel">images/pxeboot/vmlinuz</file> <file type="initrd">images/pxeboot/initrd.img</file> <file type="boot.iso">images/boot.iso</file> </tree> Each tree has a unique ID. Like the composes, it can be any freeform string, but it must be unique among trees. (A better choice might be something like "rawhide-20070122.i386" - this is still open to change.) In the xml structure we've got the name of the parent compose, the 'family' string (the second line of .discinfo), the version (as a floating point number), the timestamp of the tree (which I am using as the tree id, due to the fact that it's unique), and the tree's arch. Finally there's a list of important files that other applications might like to know the location of. For my purposes, those three files are the ones I care about - other applications might want other file items to be included here. Okay, so here's the questions: 1) Is this enough info to model trees and composes? What about iso sets? 2) Does anaconda have all the metadata that I'm writing out here? 3) Does this stuff look sane enough for inclusion in anaconda? Let me know what you think. I'm still not completely sure how to deal with iso sets and such. I'm sure I'm missing some vital piece of information from .discinfo that wasn't needed for my purposes, so please tell me what this lacks. Thanks in advance! -w

5 6

PATCH: Partition auto-detection and HD exploded tree installation
by Uday Prakash 31 Jan '07

31 Jan '07

Folks, Please consider the following two patches for inclusion in the anaconda and pykickstart sources. The patches provide three features, described below, related to hard drive installations. Together these features enable a kickstart and/or an exploded tree installation image to be placed on a portable storage device, such as a USB flash memory or hard drive device, and the device to be used to install one or more systems with unknown hard drive configuration. In effect, with this patch, installing from a portable storage device has the same ease of use characteristics as installing from a CD, with the added benefit that kickstart and install files can be modified directly on the device as needed, without the overhead of creating new iso images and burning CDs. The anaconda patch was created using version 11.2.0.9 of the sources. The pykickstart patch was created using version 0.36. We can provide an updated patches against the most current versions, if helpful. Given the rate at which sources are changing, we decided to hold off until someone in anaconda has had a chance to review the proposed patches and suggest changes, if needed. DOWNLOAD PATCHES ---------------- * The anaconda version 11.2.0.9 patch can be downloaded from http://www.abodiosoftware.com/patches/anaconda-11.2.0.9_abodio.patch * The pykickstart version 0.36 patch can be downloaded from http://www.abodiosoftware.com/patches/pykickstart-0.36_abodio.patch PATCH FEATURES -------------- 1. Partition auto-detection. The patch allows the partition to be left unspecified when using the harddrive method for kickstart and install locations, and the item (kickstart or installtree) to be located by iterating through available partitions. Specifically, the kickstart and method options can now be specified as follows on the command line (note the empty partition section between the two colons): ks=hd::/path/to/ks.cfg, and method=hd::/path/to/install/files Within the kickstart file, a hard drive install can be specified as follows (note the lack of a --partition directive): harddrive --dir=/path/to/install/files 2. Exploded tree support. The patch enables harddrive installation from an exploded tree, analogous to NFS installations. As a side effect, it also provides support for a RHupdates folder for an exploded tree installation. 3. Device modification protection. By default, the patch removes partitions on the harddrive containing the kickstart and/or install iso/tree from the default set to be formatted/partitioned. This can be overridden manually within the installer UI or by kickstart. Likewise, the install/kickstart harddrive is removed as a candidate for boot record modifications. This can similarly be overridden by kickstart. IMPLEMENTATION DETAILS ---------------------- 1. Partition auto-detection Previously, loader.c called the setMethodFromCmdLine()function as soon as the "method=" argument was seen. This can't be done anymore because now the partition might not be specified, and loader will (incorrectly) identify the /path/to/install/files as the partition. To get around this, we have added a new variable -- methodFromCmdLine -- to the loaderData struct. This variable is initialized while parsing command line arguments upon seeing the "method=" argument. After the SCSI, IDE and the DASD hardware have been initialize, the setMethodFromCmdLine() function is called. A race condition was seen here, by virtue of which the setMethodFromCmdLine() function was called before all the USB devices had been recognized. To get around this, the sleep() function was used to sleep for 5 seconds. If setMethodFromCmdLine() was called without the USB devices recognized, the getPartitionsList() (used by the findPartitionsWithFile() function, described later on) function would not return a complete list of devices. If, in the case of an hd install, the partition isn't specified, the findPartitionWithFile() function is called with the supplied directory name as a parameter. This function retrieves the list of available partitions and walks through them looking for the full path to the directory on each of the partitions. It accepts two parameters: the first is the pointer to the device string (populated by this function) and the second is the file to look for on all attached devices. This function returns the first partition it finds that contains the requested directory. This implementation was chosen because it similar to the case when the "ks=" argument is encountered while parsing the command line arguments. Similarly, with this patch, the user is no longer required to specify the partition of the ks file. In this case, like before, if the partition is not specified, the findPartitionWithFile() function is called with "/path/to/ks.cfg" as a parameter, and the partition containing the path is used from then on. The ks partition is passed along to the python stage of anaconda by the --kspartition option, which is added to the anaconda language. The ks partition is also saved in the loaderData struct. Pykickstart raises an exception when neither or both of biospart and partition options are specified with the harddrive command. Since the --partition is no longer required, pykickstart was modified to not raise an exception anymore. 2. Exploded tree support To support exploded tree harddrive installation, we mount the harddrive specified by the "method=" option to /tmp/hdimage and try to find the path to a valid ISO image (one that contains a stage2.img). If a valid ISO image is found, it is mounted to /mnt/source and the URL passed to anaconda is hdiso://[dev]/[path]@/mnt/source If no such path is found, we check to see if if /tmp/hdimage contains a valid exploded tree by looking for the stage2.img in the /tmp/hdimage/images folder. In this case, the tree itself is mounted to /mnt/source and the URL passed along to the next stage is hd://[dev]/[path]@/mnt/source. This way, we know which partition is the source partition as well as the path to the relevant install files. The above approach is modeled closely after the behavior of anaconda for NFS installations, where /mnt/source is used as the "base" installation directory. In the python stage of anaconda, the HardDriveInstallMethod class is replaced by two classes HdInstallMethod and HdIsoInstallMethod, analogous to the NfsInstallMethod and NfsIsoInstallMethod classes. HdInstallMethod is identical to NfsInstallMethod except for the URL parsing logic. HdIsoInstallMethod, on the other hand, extends both HdInstallMethod and NfsIsoInstallMethod so that there is minimal code redundancy. 3. Device modification protection The anaconda.id.diskset contains a list of blacklisted devices that should not be used by default by the anaconda partitioner; this list includes both the ks and source devices. Methods returning the ks and source devices are also added to the DiskSet class. A compareDrives() function is added to DiskSet that extends the functionality of isys.compareDrives() by adding in a check against the blacklisted devices. If one of the two devices appears on the blacklist, then this device is considered 'smaller' in comparison to the other. If, on the other hand, the devices are jointly present or absent from the blacklist, then the standard isys.compareDrives() function is called to compute the return value. All references to isys.compareDrives() have thus been replaced with anaconda.id.diskset.compareDrives() in order to comply with the necessary changes in this patch. In the bootloaderSetupChoices() function, when the updateDriveList() method is called, a sorted list (using the DiskSet.compareDrives() method) is passed along as well. This ensures that none of the blacklisted devices are set as the primary boot device. CHANGES NOT AFFECTING BEHAVIOR ------------------------------ The mountHardDrive() function is now a state machine similar to all the other install methods' "mounting functions." TEST CASES ---------- The following tests were performed with the aforementioned changes. Each install method was tested with and without specifying the partition of the kickstart file and source files independently. Tests were performed by installing Fedora 6 on an i386 machine. The version of booty used for testing was 0.82 and the version of pykickstart used was 0.36. All tests passed (both text and graphical installations): --------------------------------------------------------- |Install Type | KS | METHOD | | --------------------------------------------- | |w/ dev|w/o dev|remote|w/ dev|w/o dev|remote| |---------------------------------------------------------- | HDISO | Y | Y | Y | Y | Y | Y | | HD | Y | Y | Y | Y | Y | Y | | NFSISO | Y | Y | Y | N/A | N/A | N/A | | NFS | Y | Y | Y | N/A | N/A | N/A | | HTTP | Y | Y | Y | N/A | N/A | N/A | --------------------------------------------------------- Fedora Core 6 comes with Anaconda Version 11.1.1.3-1, so I put the files modified between versions 11.1.1.3-1 and 11.2.0.9 in the RHupdates directory, and placed it at the same level as the Fedora directory in the exploded tree. This way I also verified that the RHupdates directory is used during the installation. For ISO installations, I created an updates.img and placed it one level up from the ISO files. BUGS ---- We are not aware of any bugs at this time. However, any bugs should be reported to me - Uday Prakash - by email to uprakash(a)abodiosoftware.com.

3 4

pkgorder patch
by Jesse Keating 30 Jan '07

30 Jan '07

The recent change to packageorder seems to have broken rawhide. This patch makes it work again, but this seems fragile and not compatible with RHEL, nor with any compose that might still have rpms in Product/RPMS/ I also switched to using os.path.join to create the path, seems a little cleaner. -- Jesse Keating Release Engineer: Fedora

2 3

kmod support in Anaconda
by Jack Neely 29 Jan '07

29 Jan '07

Folks, I'd like for RHEL5's Anaconda to be able to not only install my OpenAFS kmod but install the right kmod variant for PAE, xen, etc. I've been working on the fedorakmod plugin for Yum for a bit during the summer but got stumped on a yum bug. Yesterday, I spent way too much time figuring out the exact bug and making fedorakmod work around it. With the plugin, Yum is now able to install all of the needed kmod packages for a specific kernel module. So, upstream is here: https://linuxczar.net/svn/slack/trunk/fedorakmod/ The plugin is also included in CVS head for yum-utils. Testing, feedback, and patches are welome. What else needs to be done to have this included in Anaconda? Jack -- Jack Neely <jjneely(a)ncsu.edu> Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89

3 3

detection of boot media...
by James Olin Oden 29 Jan '07

29 Jan '07

Hi All, So presently today, as I understand things there is no way that I can see to simply tell anaconda to use the media I booted from to acquire the kickstart file. When you specify "cdrom" that means the first cdrom not the one I booted from (some systems you can boot from the bottom cdrom). In cases where I use a usb flash drive I have to specify the precise device name, which makes the syslinux config particular to a certain hardware and which port the USB drive was plugged into. This is posing problems for us when we try to distribute one CDROM that just does the right thing. I know where in loader to patch this, but what I don't know is how to detect from what device I booted. So my first question is how do I detect from which device I booted? An alternate strategy is to "scan" for the device. Such that if one specified cdrom, anaconda would look on each cdrom it found till it found a device. This could not be the default behavior, so I'm looking in this case for a reasonable way denote this. Would you guys prefer a --scanks/--scanForKS option to be used in conjuction with the ks=$dev:$path URL, or some way to specify within the URL, like ks=$dev(scan):$path? With the find it I on the media I booted from would you like its device tag to be something like "bootmedia:" or something else? Thanks...james

4 5

PATCH: bad calloc in the loader
by Kiyoaki Matsugae 28 Jan '07

28 Jan '07

Folks, here is a attached a buf fix for anaconda Description of problem: calloc is incorrectly called in the loader. /* while playing with it and kickstart, i had loader core dump in fopen ( malloc to be more precise ) without any valid reason. */ there are serveral incorrect calloc calls : for example : loaderData->methodData = calloc(sizeof(struct hdInstallData *) this should be loaderData->methodData = calloc(sizeof(struct hdInstallData) we want to alloc the struct size, not the size of the pointer to the struct ! Best regards, Kiyo

1 0

Bump CD size in splittree to 685 instead of 640
by Jesse Keating 23 Jan '07

23 Jan '07

We shipped FC6 with a set size of 685, could we make this the default in splittree? -- Jesse Keating Release Engineer: Fedora

2 8

Two questions about RPM packages
by Ali Majdzadeh 21 Jan '07

21 Jan '07

Hello all I have two questions regarding RPM packages installed during installation. First, is it possible to indicate which RPM package should be installed first or last? For example, I want an RPM package to get installed after all of the packages being installed. Second, how is it possible to specify the order in which a group of related RPM packages should be installed? For example, Xfce desktop contains ~30 RPM packages, i want to specify the installation order. Is it possible? Best Regards Ali Majdzadeh Kohbanani

5 11

Issue with i2o Raid devices?
by David Hopkins 20 Jan '07

20 Jan '07

I have several systems with Adaptec 2010s zero channel i2o controllers. During re-install, the controller is not detected. specifying linux noprobe and then manually selecting the controller (i2o_block) still does not detect the controller nor the drives. Controller has latest bios installed. shadowconnect reports that the controllers are supported, and suggested that I contact this list to see if there is a known issue or workaround with anaconda. Sincerely, Dave Hopkins

1 0

PATCH: fix network device handling in text mode
by Elliot Peele 18 Jan '07

18 Jan '07

Currently textw/network_text.py references net.useIPv{4,6} which doesn't exist. This patch pulls this information from the network device object. Elliot

2 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 2007