Anaconda-devel June 2007

anaconda-devel@lists.fedoraproject.org

19 participants
18 discussions

Re: iBFT support while Installation and Booting
by Prasanna Mumbai 08 Jun '07

08 Jun '07

On 6/5/07, Doug Maxey <dwm(a)enoyolf.org> wrote: > > > On Tue, 05 Jun 2007 16:30:44 PDT, "Prasanna Mumbai" wrote: > > Hi all, > > > > Currently, Anaconda can install to an iSCSI LU but doesn't make use of > the > > iBFT, if it's available. The iBFT (iSCSI Boot Firmware Table) is > written to > > ibft is also available (of sorts) on ppc64. > > > memory by iSCSI bootable NICs. > > The parameters are stashed by bios/ofw on the platform, not by the nic. If the case is LOM (Lan on Motherboard) then definitely bios will store the parameter, whereas in case of NIC, the NIC takes care of storing the iBFT into memory. > Recently patches were accepted that created > > the fwparam_ibft application, which would output the iBFT. The > forthcoming > > patches to Open-iSCSI, mkinitrd and Anaconda will allow Anaconda to > install > > to an iSCSI LU using the iBFT. > > "iscsistart" patch: added options to iscsistart, one for reading and > > displaying iBFT and other option will let you read the iBFT and > establish a > > connection to the LU. > > > > "fwparam_ibft" patch: changed function main to fwparam_ibft & adds > > fwparam_ibft.c and fwpwaram_ibft.h to /usr directory and deletes the > > /util/fwparam directory. fwparam_ibft.c would get built as a part of > > iscsistart application so as to give the functionality for the options > > provided in the above patch. > > > > "anaconda" patch: Instead of calling fwparam_ibft and parsing the > output it > > only needs to call iscsistart with the new "-b" option. > > Why put the code in iscsistart? The fwparam_ibft can be built to > operate correctly on the the given platform with the patch in > Message-id: <30121.1173910134(a)bebe.enoyolf.org> > Subject: [RFC PATCHSET] add fwparam_ppc for open-iscsi Using fwparam_ibft as a stand alone application to read the iBFT, and script around it while install & boot time, and using different scripting languages for different distros have issues of maintainability which i discussed in Message-ID: < 463F80C1.3020402(a)cs.wisc.edu> and proposed merging the applications as my solution 5 weeks back on this community. so i put the patches of merged fwparam_ibft.c and iscsistart.c for x86 architecture and in case of PPC i wanted someone to do that and give it to the maintainer as i don't have the hardware. > > > "mkinitrd" patch: Instead of inserting hard coded connection parameters > > into the initrd, the initrd will simply call "iscsistart -b" which will > > Already done with fwparam_ibft. The init file of initrd has hard coded values for connection parameters still. mkinitrd is using the fwparam_ibft to get these parameter only. he isn't using this in the init script of initrd. And also having the "glue" code around fwpwram & iscsistart will be difficult to implement in Nash (at least i feel so). ++doug > >

2 1

F7 mixing %post --nochroot and %post broken
by Phil Meyer 07 Jun '07

07 Jun '07

Some of my kickstart scripts did tricks like this: ... %post --nochroot # Set Up Applications for install mkdir /mnt/sysimage/tmp/local cp /tmp/isomedia/ks/jdk*.rpm /mnt/sysimage/tmp/local cp /tmp/isomedia/ks/livna*.rpm /mnt/sysimage/tmp/local cp /tmp/isomedia/ks/codecs.tgz /mnt/sysimage/tmp cp /tmp/isomedia/ks/fix_host /mnt/sysimage/tmp %post cd / tar xzf /tmp/codecs.tgz ... I used the nochroot to copy stuff from my custom DVD image to the hard drive where I could later mess with it during normal post. These now fail in F7, anaconda 11.2.0.66-1. It appears that /tmp/isomedia is no longer mounted at %post --nochroot. Another oddity that I have observed, is this: During install hit <F2> and verify the presence of /mnt/sysimage/usr/sbin/adduser However, a custom package that adds a user, and is installed as part of the OS load, fails to find /usr/sbin/useradd. This used to work. Thanks for looking at this!

3 3

iBFT support while Installation and Booting
by Prasanna Mumbai 06 Jun '07

06 Jun '07

Hi all, Currently, Anaconda can install to an iSCSI LU but doesn't make use of the iBFT, if it's available. The iBFT (iSCSI Boot Firmware Table) is written to memory by iSCSI bootable NICs. Recently patches were accepted that created the fwparam_ibft application, which would output the iBFT. The forthcoming patches to Open-iSCSI, mkinitrd and Anaconda will allow Anaconda to install to an iSCSI LU using the iBFT. "iscsistart" patch: added options to iscsistart, one for reading and displaying iBFT and other option will let you read the iBFT and establish a connection to the LU. "fwparam_ibft" patch: changed function main to fwparam_ibft & adds fwparam_ibft.c and fwpwaram_ibft.h to /usr directory and deletes the /util/fwparam directory. fwparam_ibft.c would get built as a part of iscsistart application so as to give the functionality for the options provided in the above patch. "anaconda" patch: Instead of calling fwparam_ibft and parsing the output it only needs to call iscsistart with the new "-b" option. "mkinitrd" patch: Instead of inserting hard coded connection parameters into the initrd, the initrd will simply call "iscsistart –b" which will create the connection using the newly modified iscsistart. *These patches won't support PPC, as I don't have the required H/W to test if I do the coding. So some guys should help me out. Changes required in PPC are: the main should be replaced with fwparam_ibft providing the required functionality similar to fwparam_ibft.c* ~Cheers Prasanna

1 0

partitions.autoClearPartType not getting set -- F7
by Phil Meyer 05 Jun '07

05 Jun '07

I am getting "Invalid clear part type in doClearPartAction". It is refrencing autopart.py lines 1084 and 1228 Entering the debugger shows: (Pdb) print partitions.autoClearPartType None (Pdb) The lines in my kickstart scripts have not changed: #Partition clearing information clearpart --drives sda --initlabel I tried: #Partition clearing information clearpart --drives=sda --initlabel With the same results. All I want is to clear the install drive. Is there now a new and better way that /usr/share/doc/anaconda-11.2.0.66/kickstart-docs.txt does not mention? Thanks!

2 4

One of biospart or partition options must be specified
by Phil Meyer 05 Jun '07

05 Jun '07

This seems to be a bug, but I don't find a discussion of it. When specifying a media location as hard disk, the following syntax has worked in the past: # Use hard drive installation media harddrive --dir=/ --partition=sdb2 In fact, those lines were generated by the new system-config-kickstart. However, if you try to run system-config-kickstart against a file it just created with these lines in it, you get a pop up with this message: "One of biospart or partition options must be specified" Obviously, the biospart is a new key word, but the check for the new key word broke the old one! :) All of my kickstart files specify where to locate the media, and they are all broken now. Folks are asking for F7 installs, but this is a show stopper, since anaconda errors out over this. Thanks!

2 2

Updating an older Fedora Core 5 installer to feature newer kernel modules
by Matthew Bloch 05 Jun '07

05 Jun '07

Hi there, I'm trying to solve a long-standing problem with installation of CentOS & Fedora on our nForce-430-based motherboards. The forcedeth kernel module has been pretty fast-moving over the last few kernels and to support our current boards, we need a really fresh version which is generally only found in 2.6.19 or 2.6.20. nVidia backport these drivers to earlier kernels here: http://www.nvidia.com/object/linux_nforce_1.21.html Since we can only perform network network installs, I am trying to work out a general way of retro-fitting the lastest nForce drivers into a given Fedora Core or CentOS install, and I understand the anaconda loader program is the key to this. Unfortunately "use a newer distro" isn't an option in a few cases where customers want a specific Fedora version for support of some random commercial software - right now I am struggling to get FC5 working, but it would be nice if this would fix Centos3/4 which are popularly requested as well. Also despite FC5 being listed as being included in nVidia's binaries, they don't provide a driver disc image. They claim that the FC5 driver should support installation at least, and the RPMs are just to bring it bang up to date after installation. This isn't true on our newest motherboards, it just doesn't seem to spot that the network chip exists. What I've tried so far is to extract the stock pxeboot/initrd.img and the contained modules/modules.cgz files. Then I add in the .ko files from the RPMs that nVidia supply for FC5, then rebuild it all with cpio / gzip. Unfortunately anaconda still says it doesn't have a driver "for the specified installation type", even though I'm 99% sure that the forcedeth.ko file bring up an eth0 (not sure how to launch a shell from the loader to check ;) ). I even tried copying the FC5 x86_64/os directory onto a local drive, then re-launched the network installation and asked it to install off a local hard drive. Again the "no driver found for specified installation type" complaint, even though it offered to load a driver disk off the filesystem on /dev/sda1 which it could clearly access ;-) So from that last problem, I guessed that even if I've put some working driver modules in there, I needed to add some PCI IDs to a list or two. At this point I'm guessing, but I found the modules/pci.ids file and modules/modules.aliases files in the initrd. I've tried altering these to contain information about the nForce drivers (10de:03ef for the network chip, and 10de:03f6 for the SATA chip) but I still see the "no driver found for specified installtion type" for both hard disc and network installs. I've attached my initrd-rebuilding script which I've used for my experiments - can anyone with more expertise on anaconda advise on a next step? Is "slipstreaming" kernel modules possible in this way, or is there a smarter way of going about what I want to do? Thanks, -- Matthew #!/usr/bin/ruby # # This script rebuilds the given redhat PXE initrd image with modules found # in RPMs. This is useful to update installers with newer kernel modules, # whether the manufacturer has supplied a driver disk or not - as long as # there are some RPMs, you can use them to rebuild and run the installer. # Save some typing # require 'find' require 'fileutils' include FileUtils def xsys(cmd) return if system(cmd) STDERR.print "*** Error running: #{cmd}\n" exit $?.exitstatus end class Dir def self.mkdir_and_work_in(d) mkdir(d) unless File.directory?(d); prev = Dir.pwd; chdir(d); yield; chdir(prev) end end MODULE_PATH = /\.ko$/ # Sanity check on arguments # initrd, initrd_out, *rpms = *ARGV if ARGV.length < 3 || [initrd, *rpms].select { |f| !File.exists?(f) }.length > 0 STDERR.print "Syntax: #{$0} <original initrd.img> <new initrd.img> <rpm 1> [rpm 2 ... ]\n" exit 1 end if File.exists?(initrd_out) STDERR.print "Won't overwrite #{initrd_out}, please move it\n" exit 2 end # Do our work in a temporary directory # Dir.mkdir("/tmp/rebuild.#{$$}") #at_exit { rmtree "/tmp/rebuild.#{$$}" } Dir.chdir("/tmp/rebuild.#{$$}") # Extract initrd # Dir.mkdir_and_work_in("x_initrd") do xsys("gunzip <#{initrd} | cpio -id") end # Extract modules inside initrd, find correct path to put our extra modules # Dir.mkdir_and_work_in("x_modules") do xsys("gunzip <../x_initrd/modules/modules.cgz | cpio -id") end module_path = nil Find.find("x_modules") do |file| next unless MODULE_PATH.match(file) module_path = file.split("/")[0..-2].join("/") break end raise ArgumentError.new("Couldn't find any .ko files in extracted modules.cgz") if module_path.nil? # Extract all the RPMs # rpms.each_with_index do |rpm,idx| Dir.mkdir_and_work_in("x_rpm_#{idx}") do xsys("rpm2cpio #{rpm} | cpio -id") end end # Scout for modules, copy them into our x_modules directory # rpms.length.times do |idx| Find.find("x_rpm_#{idx}") do |file| if MODULE_PATH.match(file) cp(file, module_path) STDERR.print "Copied #{file.split('/')[-1]}\n" end end end # Freshen pci.ids file - probably not necessary, just guessing as it seems # to be the cleanest way to get our nVidia PCI IDs listed. # rm("x_initrd/modules/pci.ids") xsys("wget -q -O x_initrd/modules/pci.ids http://pciids.sourceforge.net/pci.ids") # Add some PCI aliases - total guesswork based on existing entries # File.open("x_initrd/modules/modules.alias", "a") do |fh| fh.print <<__ alias pci:v000010DEd000003efsv*sd*bc*sc*i* forcedeth alias pci:v000010DEd000003f6sv*sd*bc*sc*i* sata_nv __ end # Make a new modules.cgz archive # Dir.mkdir_and_work_in("x_modules") do xsys("find . | cut -f2- -d/ | cpio -o -H newc | gzip >../x_initrd/modules/modules.cgz") end # Make a new initrd.img, move it to the right place # Dir.mkdir_and_work_in("x_initrd") do xsys("find . | cut -f2- -d/ | cpio -o -H newc | gzip >../initrd.img") end mv("initrd.img", initrd_out)

3 3

Kickstart over FTP with username and password integration
by Jasper Hartline 04 Jun '07

04 Jun '07

Upon testing Anaconda from an older era, using for example: vmlinuz initrd=initrd.img ksdevice=eth0 ks=ftp://username:password@host/path/ks.cfg I notice FTP does not work unless it is an anonymous FTP server usage for which to retrieve the kickstart file. I am trying to patch an older Anaconda's source archive to allow this, but I am unsure exactly where it is handled in Anaconda's source code. I have been looking around in the loader2/ directory and I see ftp.c and ftp.h which seem to deal with it, however after looking at some diff output between the old Anaconda's loader2/ftp.c and the latest Anaconda's loader2/ftp.c I am not able to locate anything that stands out as a major change, so I'm almost expecting this to be a bug in the older Anaconda, which I would still like to fix. Can someone send me in the right direction as far as locating up to date source code within Anaconda that deals with the ks=ftp:// option to the loader? Thanks. J. Hartline

2 1

Errors when compiling anaconda 11.1.1.3
by Olivier D 02 Jun '07

02 Jun '07

Hello, I'm trying to compile anaconda 11.1.1.3 : rpmbuild -ba anaconda.spec I'm getting the following errors about wireless.h : cc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -Werror -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DUSESELINUX=1 -I/usr/include/python2.4 -I.. -DHAVE_NFS -I/usr/include/glib- 2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libdhcp -I/usr/include/dhcp4client -I/usr/include/dhcp6client -fPIC -o wireless.lo wireless.c In file included from wireless.c:29: /usr/include/linux/wireless.h:636: error: expected specifier-qualifier-list before '__s32' /usr/include/linux/wireless.h:648: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token /usr/include/linux/wireless.h:663: error: expected specifier-qualifier-list before '__s32' /usr/include/linux/wireless.h:674: error: expected specifier-qualifier-list before '__u8' /usr/include/linux/wireless.h:690: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:703: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:730: error: expected specifier-qualifier-list before '__u8' /usr/include/linux/wireless.h:792: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:806: error: expected specifier-qualifier-list before '__u16' /usr/include/linux/wireless.h:820: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:828: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:837: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:849: error: expected specifier-qualifier-list before '__u16' /usr/include/linux/wireless.h:872: error: 'IFNAMSIZ' undeclared here (not in a function) /usr/include/linux/wireless.h:887: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:931: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:1032: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:1050: error: expected specifier-qualifier-list before '__u16' cc1: warnings being treated as errors wireless.c: In function 'get_wreq': wireless.c:34: warning: value computed is not used wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' wireless.c: In function 'set_essid': wireless.c:81: error: 'struct iw_point' has no member named 'flags' wireless.c:82: error: 'struct iw_point' has no member named 'pointer' wireless.c:83: error: 'struct iw_point' has no member named 'length' wireless.c:85: error: 'struct iw_point' has no member named 'flags' wireless.c:86: error: 'struct iw_point' has no member named 'pointer' wireless.c:87: error: 'struct iw_point' has no member named 'length' wireless.c: In function 'get_essid': wireless.c:108: error: 'struct iw_point' has no member named 'pointer' wireless.c:109: error: 'struct iw_point' has no member named 'length' wireless.c:110: error: 'struct iw_point' has no member named 'flags' wireless.c:120: error: 'struct iw_point' has no member named 'pointer' wireless.c: In function 'set_wep_key': wireless.c:193: error: 'union iwreq_data' has no member named 'data' wireless.c:194: error: 'union iwreq_data' has no member named 'data' wireless.c:195: error: 'union iwreq_data' has no member named 'data' wireless.c:198: error: 'union iwreq_data' has no member named 'data' wireless.c:199: error: 'union iwreq_data' has no member named 'data' wireless.c:200: error: 'union iwreq_data' has no member named 'data' wireless.c: In function 'set_managed': wireless.c:221: error: 'union iwreq_data' has no member named 'mode' make[1]: *** [wireless.lo] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/anaconda-11.1.1.3/isys' make: *** [subdirs] Error 1 error: Bad exit status from /var/tmp/rpm- tmp.41753 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.41753 (%build) infos about /usr/include/linux/wireless.h : /* * This file define a set of standard wireless extensions * * Version : 20 17.2.06 * * Authors : Jean Tourrilhes - HPL - <jt(a)hpl.hp.com> * Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved. */ Any idea ? Olivier

4 5

2026

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 2007