From Joseph.Cipolla at wellcare.com Wed Dec 3 22:06:00 2008 From: Joseph.Cipolla at wellcare.com (Cipolla, Joseph) Date: Wed, 3 Dec 2008 17:06:00 -0500 Subject: Bonding interfaces in %post Message-ID: <1B30BF9AA99B65419E4B6A3DB905D7965F243B@EX06.ad.wellcare.com> I am attempting to create a bonded interface from two NICs on RHEL 5.1, but I'm running into a strange problem. When the system is completed with the kickstart and reboots, it renames the ifcfg-eth0/1 files to ifcfg-eth0/1.bak and changing the interfaces to DHCP. The ifcfg-bond0 file remains unchanged though. From what I've been able to find on the net, there is something in the boot sequence that requires HWADDR be set in the ifcfg-ethN files and will overwrite them if not found. Once I copy the files back and restart the network service, everything is fine. And subsequent reboots do not mess with the files again, even though they are still missing the HWADDR field. My question is this: Can this function be disabled or bypassed? If not, then will I have to determine the HWADDR of each interface prior to creating the ifcfg-ethN files? Or will anaconda be supporting interface bonding in future releases? Thanks, Joseph Cipolla Senior Systems Engineer WellCare Health Plans, Inc. 8735 Henderson Road Ren 1-1 Tampa, FL 33634 813-290-6200 x1775 Privacy Notice: This electronic mail message, and any attachments, are confidential and are intended for the exclusive use of the addressee(s) and may contain information that is proprietary and that may be Individually Identifiable or Protected Health Information under HIPAA. If you are not the intended recipient, please immediately contact the sender by telephone, or by email, and destroy all copies of this message. If you are a regular recipient of our electronic mail, please notify us promptly if you change your email address. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Wed Dec 3 22:12:37 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Dec 2008 16:12:37 -0600 Subject: Timezone specification Message-ID: I found that with F-10, I can no longer use timezone --utc US/Central to specify my timezone. For some reason this is no longer valid, even though it has been a valid timezone for Unix systems since as far as I can remember. The installer drops me into the timezone chooser, and unfortunately that makes it rather difficult to choose a city in US/Central, because it either suggests Monterrey (which has different DST rules) or forces me to somehow know the myriad DST rules for all of the little cities in Indiana which are represented on the map in preference to cities like Houston or Dallas. My complaints about that have always been closed NOTABUG, though, so I guess there's no point in complaining here, except that I honestly do not know how to specify the proper timezone for my location any longer. Does anyone happen to know? - J< From timm at fnal.gov Wed Dec 3 22:16:26 2008 From: timm at fnal.gov (Steven Timm) Date: Wed, 03 Dec 2008 16:16:26 -0600 (CST) Subject: Timezone specification In-Reply-To: References: Message-ID: On Wed, 3 Dec 2008, Jason L Tibbitts III wrote: > I found that with F-10, I can no longer use > > timezone --utc US/Central timezone --utc America/Chicago should work. Steve > > to specify my timezone. For some reason this is no longer valid, even > though it has been a valid timezone for Unix systems since as far as I > can remember. > > The installer drops me into the timezone chooser, and unfortunately > that makes it rather difficult to choose a city in US/Central, because > it either suggests Monterrey (which has different DST rules) or forces > me to somehow know the myriad DST rules for all of the little cities > in Indiana which are represented on the map in preference to cities > like Houston or Dallas. My complaints about that have always been > closed NOTABUG, though, so I guess there's no point in complaining > here, except that I honestly do not know how to specify the proper > timezone for my location any longer. Does anyone happen to know? > > - J< > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > -- ------------------------------------------------------------------ Steven C. Timm, Ph.D (630) 840-8525 timm at fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader. From buchholz at easystreet.net Wed Dec 3 22:19:56 2008 From: buchholz at easystreet.net (Don Buchholz) Date: Wed, 03 Dec 2008 14:19:56 -0800 Subject: Timezone specification In-Reply-To: References: Message-ID: <4937060C.20903@easystreet.net> Jason L Tibbitts III wrote: > I found that with F-10, I can no longer use > > timezone --utc US/Central > > to specify my timezone. For some reason this is no longer valid, even > though it has been a valid timezone for Unix systems since as far as I > can remember. > > The installer drops me into the timezone chooser, and unfortunately > that makes it rather difficult to choose a city in US/Central, because > it either suggests Monterrey (which has different DST rules) or forces > me to somehow know the myriad DST rules for all of the little cities > in Indiana which are represented on the map in preference to cities > like Houston or Dallas. My complaints about that have always been > closed NOTABUG, though, so I guess there's no point in complaining > here, except that I honestly do not know how to specify the proper > timezone for my location any longer. Does anyone happen to know? > > - J< America/Chicago ... on my RHEL-4 system, America/Chicago and US/Central are identical (using cmp(1)). From bjs at redhat.com Wed Dec 3 22:30:43 2008 From: bjs at redhat.com (Bryan J Smith) Date: Wed, 03 Dec 2008 17:30:43 -0500 Subject: Timezone specification In-Reply-To: References: Message-ID: <1228343443.4272.55.camel@localhost.localdomain> On Wed, 2008-12-03 at 16:12 -0600, Jason L Tibbitts III wrote: > I found that with F-10, I can no longer use > timezone --utc US/Central > to specify my timezone. For some reason this is no longer valid, even > though it has been a valid timezone for Unix systems since as far as I > can remember. > The installer drops me into the timezone chooser, and unfortunately > that makes it rather difficult to choose a city in US/Central, because > it either suggests Monterrey (which has different DST rules) or forces > me to somehow know the myriad DST rules for all of the little cities > in Indiana which are represented on the map in preference to cities > like Houston or Dallas. My complaints about that have always been > closed NOTABUG, though, so I guess there's no point in complaining > here, except that I honestly do not know how to specify the proper > timezone for my location any longer. Does anyone happen to know? First off, I absolutely know Anaconda has *0* control over this, but it is related to the Zoneinfo Data (tzdata) package, which has upstream considerations (see the following items). The actual files are under /usr/share/zoneinfo. If US/Central does not exist, that's the root cause. Second, per Zoneinfo, the standard pathname is region/locale, where the region is typically continent (or continent set, like "America") and the locale is the largest city in a that timezone, for the continent. E.g., instead of US/Central, you use America/Chicago. Third, there are exceptions for regions/countries that use different offsets or, more commonly, daylight savings time (especially regions/countries that use a dynamic ruleset, one that is often decided with little warning). *AVOID* those unless you need them. E.g., America/Indiana/(city-county), America/Argentina/(city), etc... WHEN IN DOUBT (short of looking in /usr/share/zoneinfo, the Wikipedia entry is often updated and typically matches a late tzdata release): http://en.wikipedia.org/wiki/List_of_zoneinfo_timezones Lastly, Olson, Eggert and the rest of the Zoneinfo gang have long deprecated many of the compatibility pathnames (e.g., US/Central) and were trying to purge a lot of the legacy pathnames from their reference tzdata distribution. I don't know if they have done that or not more recently (it's been about 18 months since I have been actively tracking Zoneinfo developments). Relying on that long deprecated path is not a good idea. -- Bryan J Smith - Senior Consultant - Red Hat GPS SE US mailto:bjs at redhat.com +1 (407) 489-7013 (Mobile) mailto:b.j.smith at ieee.org (non-RH/ext to Blackberry) ----------------------------------------------------- For every dollar you spend on Red Hat solutions, you not only fund the leading community development re- source, but you receive the #1 IT industry leader in corporate value. http://www.redhat.com/promo/vendor/ From terry.mcintyre at gmail.com Wed Dec 3 23:15:09 2008 From: terry.mcintyre at gmail.com (Terry McIntyre) Date: Wed, 3 Dec 2008 15:15:09 -0800 Subject: Timezone specification In-Reply-To: <1228343443.4272.55.camel@localhost.localdomain> References: <1228343443.4272.55.camel@localhost.localdomain> Message-ID: <67f096ea0812031515vc8d63b5sf3049c2b38bcc2fe@mail.gmail.com> We seem to be going backwards. Before the invention of timezones, every railroad stop had a different time "zone". Then we divided the country into Eastern, Central, Mountain, and Pacific timezones. Since then, cities and states and other regions have chosen to balkanize the country into ever-smaller divisions. There is disagreement about when and whether to advance and retreat with the seasons. Soon, we'll be where we started: every railroad stop with a different time. This is progress? From painapur at packetmotion.com Thu Dec 4 06:55:27 2008 From: painapur at packetmotion.com (Priya Ainapur) Date: Wed, 3 Dec 2008 22:55:27 -0800 Subject: Trouble in setting the network through kick start in rescue mode boot for centos-5.1 Message-ID: <0C8D9E14F6D930488EF795D698B584AE1339A6@pmi00exf01.us.packetmotion.com> Hi all, I am trying to write a kick start file for booting the centos-5.1 in rescue mode. The command I used to build the iso image is: mkisofs -o CentOS-rescue.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -q -R -J -v -T . My kick start file looks as shown below: # Kickstart file # Make it install in text mode text # Full install of OS instead of upgrade install # Use cdrom for install cdrom lang en_US.UTF-8 keyboard us # network --bootproto=static --device=eth0 --onboot=on --ip 192.168.1.2 --netmask 255.255.255.0 --nameserver 172.16.1.3,172.16.1.4 --gateway 192.168.1.1 #### END Even though I gave the network settings configuration in the kick start file, the anaconda installer pops up the network settings confirmation window when I boot from the CD. Please help me in solving this. Thanks in advance Priya -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjs at redhat.com Thu Dec 4 14:12:16 2008 From: bjs at redhat.com (Bryan J Smith) Date: Thu, 04 Dec 2008 09:12:16 -0500 Subject: Timezone specification In-Reply-To: <67f096ea0812031515vc8d63b5sf3049c2b38bcc2fe@mail.gmail.com> References: <1228343443.4272.55.camel@localhost.localdomain> <67f096ea0812031515vc8d63b5sf3049c2b38bcc2fe@mail.gmail.com> Message-ID: <1228399936.4125.12.camel@localhost.localdomain> On Wed, 2008-12-03 at 15:15 -0800, Terry McIntyre wrote: > We seem to be going backwards. Before the invention of timezones, > every railroad stop had a different time "zone". Then we divided the > country into Eastern, Central, Mountain, and Pacific timezones. Since > then, cities and states and other regions have chosen to balkanize the > country into ever-smaller divisions. There is disagreement about when > and whether to advance and retreat with the seasons. Soon, we'll be > where we started: every railroad stop with a different time. This is > progress? Actually, by the time the US DST changes of the Energy Act of 2005 went into effect, virtually all of North American (with far more rare exception) is now all on the same. This includes most (now all?) of the counties in Indiana, and most (now all?) of the provinces and territories of Canada, even a few in the Caribbean too. Now you still have the different Zoneinfo files, for historical purposes. I.e., Zoneinfo provides offset for past dates/times as well, so you still needs those for historical purposes. But that's unavoidable in general. You _must_always_ keep historical information, but that's hardly the fault of the "solution." Much of the world (even Israel finally started putting down its logic more recently IIRC, leaving only a small handful of nations/cities that still do not) has been steadily reducing the number of variations. It was far, far, far worse some 50-60 years ago. It was _never_ as uniform as you say it was prior. ;) The Region/City pathing has been repeatedly shown to be approach with least issues. It does not rely on the names of a country, which may change or -- worse yet -- not be recognized by some nations (especially nearby nations using the same offsets), where as continents never and cities very, very infrequently ever change in name. I give Olson-Eggert a lot of credit for coming up with a system that changes the least, and is very effective at addressing regular issues (notices are regular, due to various changes). Even Microsoft, let IEEE POSIX / OpenGroup SUS or even the IETF, never came up with anything better. -- Bryan J Smith - Senior Consultant - Red Hat GPS SE US mailto:bjs at redhat.com +1 (407) 489-7013 (Mobile) mailto:b.j.smith at ieee.org (non-RH/ext to Blackberry) ----------------------------------------------------- For every dollar you spend on Red Hat solutions, you not only fund the leading community development re- source, but you receive the #1 IT industry leader in corporate value. http://www.redhat.com/promo/vendor/ From painapur at packetmotion.com Fri Dec 5 11:58:04 2008 From: painapur at packetmotion.com (Priya Ainapur) Date: Fri, 5 Dec 2008 03:58:04 -0800 Subject: FW: trying to mount CD device hda ejecting /tmp/cdrom Message-ID: <0C8D9E14F6D930488EF795D698B584AE133A1E@pmi00exf01.us.packetmotion.com> Hi I am trying to boot in cent OS in rescue mode in kick start mode. The kick start file is present on the CDROM. I have built the custom iso image using the following commad. mkisofs -o CentOS-rescue_probe.iso -r -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size=4 -boot-info-table -R -J -v -T . I have burned this iso image to CD using magic iso software. But when I boot from this CD, I am getting below error when I see in ctrl+alt+F3 screen. "trying to mount CD device hda ejecting /tmp/cdrom" Please help me. Thanks in advance Priya -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Fri Dec 5 14:47:39 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 05 Dec 2008 09:47:39 -0500 Subject: Bonding interfaces in %post In-Reply-To: <1B30BF9AA99B65419E4B6A3DB905D7965F243B@EX06.ad.wellcare.com> References: <1B30BF9AA99B65419E4B6A3DB905D7965F243B@EX06.ad.wellcare.com> Message-ID: <49393F0B.40407@redhat.com> Cipolla, Joseph wrote: > > > I am attempting to create a bonded interface from two NICs on RHEL > 5.1, but I'm running into a strange problem. When the system is > completed with the kickstart and reboots, it renames the ifcfg-eth0/1 > files to ifcfg-eth0/1.bak and changing the interfaces to DHCP. The > ifcfg-bond0 file remains unchanged though. From what I've been able > to find on the net, there is something in the boot sequence that > requires HWADDR be set in the ifcfg-ethN files and will overwrite them > if not found. Once I copy the files back and restart the network > service, everything is fine. And subsequent reboots do not mess with > the files again, even though they are still missing the HWADDR field. > > My question is this: Can this function be disabled or bypassed? If > not, then will I have to determine the HWADDR of each interface prior > to creating the ifcfg-ethN files? Or will anaconda be supporting > interface bonding in future releases? > Of potential interest, though not quite released yet (coming this week), Cobbler 1.4 will have support for creating the code to set up bonding in %post, which can be set up through the command line or the web application. See https://fedorahosted.org/cobbler/wiki/AdvancedNetworking for some early documentation. Might not be for everyone but I wanted to throw that out there. Comments on the implementation are most definitely welcome. --Michael > Thanks, > > *Joseph Cipolla* > Senior Systems Engineer > WellCare Health Plans, Inc. > 8735 Henderson Road > Ren 1-1 > Tampa, FL 33634 > 813-290-6200 x1775 > > Privacy Notice: This electronic mail message, and any attachments, are confidential and are intended for > the exclusive use of the addressee(s) and may contain information that is proprietary and that may be > Individually Identifiable or Protected Health Information under HIPAA. If you are not the intended > recipient, please immediately contact the sender by telephone, or by email, and destroy all copies of this > message. If you are a regular recipient of our electronic mail, please notify us promptly if you change > your email address. > > ------------------------------------------------------------------------ > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list From mdehaan at redhat.com Fri Dec 5 14:48:53 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 05 Dec 2008 09:48:53 -0500 Subject: Trouble in setting the network through kick start in rescue mode boot for centos-5.1 In-Reply-To: <0C8D9E14F6D930488EF795D698B584AE1339A6@pmi00exf01.us.packetmotion.com> References: <0C8D9E14F6D930488EF795D698B584AE1339A6@pmi00exf01.us.packetmotion.com> Message-ID: <49393F55.9070600@redhat.com> Priya Ainapur wrote: > > Hi all, > > > > I am trying to write a kick start file for booting the centos-5.1 in > rescue mode. > > > > The command I used to build the iso image is: > > > > mkisofs -o CentOS-rescue.iso -b isolinux/isolinux.bin -c > isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -q > -R -J -v -T . > > > > My kick start file looks as shown below: > > > > # Kickstart file > > # Make it install in text mode > > text > > > > # Full install of OS instead of upgrade > > install > > > > # Use cdrom for install > > cdrom > > lang en_US.UTF-8 > > keyboard us > > # > > network --bootproto=static --device=eth0 --onboot=on --ip 192.168.1.2 > --netmask 255.255.255.0 --nameserver 172.16.1.3,172.16.1.4 --gateway > 192.168.1.1 > > > > #### END > > > > Even though I gave the network settings configuration in the kick > start file, the anaconda installer pops up the network settings > confirmation window when I boot from the CD. > > Please help me in solving this. > > > > > > Thanks in advance > > > > Priya > > ------------------------------------------------------------------------ > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list My first throught is that your ISO is not set up to indicate usage of the kickstart, and the kickstart is not present on the ISO. --Michael From ole.ersoy at gmail.com Sun Dec 7 02:54:11 2008 From: ole.ersoy at gmail.com (Ole Ersoy) Date: Sat, 06 Dec 2008 20:54:11 -0600 Subject: Kickstart Bug? Message-ID: <493B3AD3.7080107@gmail.com> Hi, I'm trying out kickstart with a USB on Fedora 10. I do the following: boot: linux ks=hd:sdb1:/kickstart/cfg.ks The first thing that happens is that anaconda displays a message saying "The kickstart file could not be downloaded". And then lets me edit the location of the kickstart file, which is: hd:sdb1:/kickstart/cfg.ks I just leave it as is, and press OK. The installation continues, but then asks me where the installation images are loaded? It lets me select the: /dev/sdb1 partition. In the kickstart file I have this (Written by a previous install): harddrive --partition=/dev/sdb1 --dir=/ The order in which this is listed looks like this: # Kickstart file automatically generated by anaconda. install harddrive --partition=/dev/sdb1 --dir=/ lang en_US.UTF-8 keyboard us ..... I have also tried this parameter without the directory option. Am I doing something wrong or should I file a ticket? Thanks, - Ole From clumens at redhat.com Mon Dec 8 15:13:15 2008 From: clumens at redhat.com (Chris Lumens) Date: Mon, 8 Dec 2008 10:13:15 -0500 Subject: Kickstart Bug? In-Reply-To: <493B3AD3.7080107@gmail.com> References: <493B3AD3.7080107@gmail.com> Message-ID: <20081208151314.GO15775@localhost.localdomain> > I'm trying out kickstart with a USB on Fedora 10. I do the following: > > boot: linux ks=hd:sdb1:/kickstart/cfg.ks > > The first thing that happens is that anaconda displays a message saying "The kickstart file could not be downloaded". And then lets me edit the location of the kickstart file, which is: > > hd:sdb1:/kickstart/cfg.ks This is definitely a filed bug, though I'm not finding it offhand. It's a problem with us not getting any signal when USB devices are done being detected, so we can't just sleep long enough to wait. > I just leave it as is, and press OK. The installation continues, but then asks me where the installation images are loaded? It lets me select the: > > ..... > > I have also tried this parameter without the directory option. > > Am I doing something wrong or should I file a ticket? Already filed: https://bugzilla.redhat.com/show_bug.cgi?id=474123 - Chris From ole.ersoy at gmail.com Mon Dec 8 15:18:51 2008 From: ole.ersoy at gmail.com (Ole Ersoy) Date: Mon, 08 Dec 2008 09:18:51 -0600 Subject: Kickstart Bug? In-Reply-To: <20081208151314.GO15775@localhost.localdomain> References: <493B3AD3.7080107@gmail.com> <20081208151314.GO15775@localhost.localdomain> Message-ID: <493D3ADB.7090705@gmail.com> Ah - OK - Good to know - Thanks, - Ole From clumens at redhat.com Mon Dec 8 15:21:34 2008 From: clumens at redhat.com (Chris Lumens) Date: Mon, 8 Dec 2008 10:21:34 -0500 Subject: Kickstart Bug? In-Reply-To: <493D3ADB.7090705@gmail.com> References: <493B3AD3.7080107@gmail.com> <20081208151314.GO15775@localhost.localdomain> <493D3ADB.7090705@gmail.com> Message-ID: <20081208152134.GP15775@localhost.localdomain> > Ah - OK - Good to know - Thanks, Sorry, I forgot to mention that the bug report has a comment down at the bottom with a workaround. I was going to say that in my original mail but got distracted with something else and sent it anyway. - Chris From ole.ersoy at gmail.com Mon Dec 8 15:54:45 2008 From: ole.ersoy at gmail.com (Ole Ersoy) Date: Mon, 08 Dec 2008 09:54:45 -0600 Subject: Kickstart Bug? In-Reply-To: <20081208152134.GP15775@localhost.localdomain> References: <493B3AD3.7080107@gmail.com> <20081208151314.GO15775@localhost.localdomain> <493D3ADB.7090705@gmail.com> <20081208152134.GP15775@localhost.localdomain> Message-ID: <493D4345.9090708@gmail.com> Cool - I'll check it out - Thanks again, - Ole From andrew at fiber-hosting.com Mon Dec 8 21:16:03 2008 From: andrew at fiber-hosting.com (Andrew) Date: Mon, 08 Dec 2008 14:16:03 -0700 Subject: Anaconda error Message-ID: <493D8E93.6040000@fiber-hosting.com> Hello, I keep getting an error while trying to install any version of Fedora with cobbler. While using dhcp or trying to manually set the IP Anaconda says cannot set IP and the install errors out. Here is my kickstart from my Fedora 9 profile: # kickstart template for Fedora 8 and later. # (includes %end blocks) # do not use with earlier distros #platform=x86, AMD64, or Intel EM64T # System authorization information auth --useshadow --enablemd5 # System bootloader configuration bootloader --location=mbr # Partition clearing information clearpart --all --initlabel # Use text mode install text # Firewall configuration firewall --enabled # Run the Setup Agent on first boot firstboot --disable # System keyboard keyboard us # System language lang en_US # Use network installation url --url=http://192.168.100.18/cblr/links/Fedora9-i386 # If any cobbler repo definitions were referenced in the kickstart profile, include them here. repo --name=source-1 --baseurl=http://192.168.100.18/cobbler/ks_mirror/Fedora9/os # Network information network --bootproto=dhcp --device=eth1 --onboot=on # Reboot after installation reboot # SELinux configuration selinux --disabled # Do not configure the X Window System skipx # System timezone timezone America/New_York # Install OS instead of upgrade install # Clear the Master Boot Record zerombr # Magically figure out how to partition this thing %include /tmp/partinfo %pre # Determine how many drives we have set $(list-harddrives) let numd=$#/2 d1=$1 d2=$3 cat << EOF > /tmp/partinfo part / --fstype ext3 --size=1024 --grow --ondisk=$d1 --asprimary part swap --size=1024 --ondisk=$d1 --asprimary EOF wget "http://192.168.100.18/cblr/svc/op/trig/mode/pre/profile/Fedora9-i386" -O /dev/null %end %packages %end %post wget "http://192.168.100.18/cblr/svc/op/ks/profile/Fedora9-i386" -O /root/cobbler.ks wget "http://192.168.100.18/cblr/svc/op/trig/mode/post/profile/Fedora9-i386" -O /dev/null %end From aaron at assonance.org Tue Dec 9 21:52:15 2008 From: aaron at assonance.org (Aaron Cohen) Date: Tue, 9 Dec 2008 16:52:15 -0500 Subject: Anaconda updates= boot option Message-ID: <727e50150812091352n39752b3el567a33f05063039@mail.gmail.com> I'm trying to configure PXE booting at the moment, and I've got it mostly working, except for the updates= option. Is this meant to configure a server that RPM updates are pulled from during installation or is it more limited than that? I have it specified as a local yum repository, and it does not seem to be used at all, only my http: (which I specified using method=) is being used. Is the only option to create a kickstart file that adds my repository? This seems to be for both Fedora 9 and 10. Thanks, Aaron From kpowell at redhat.com Tue Dec 9 22:35:34 2008 From: kpowell at redhat.com (Kyle Powell) Date: Tue, 09 Dec 2008 17:35:34 -0500 Subject: Anaconda updates= boot option In-Reply-To: <727e50150812091352n39752b3el567a33f05063039@mail.gmail.com> References: <727e50150812091352n39752b3el567a33f05063039@mail.gmail.com> Message-ID: <493EF2B6.7020104@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Cohen wrote: > I'm trying to configure PXE booting at the moment, and I've got it > mostly working, except for the updates= option. > > Is this meant to configure a server that RPM updates are pulled from > during installation or is it more limited than that? No. It's a method to provide updates to the anaconda installer itself. http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s3-x86-starting-kernelopts.html > Is the only option to create a kickstart file that adds my repository? It's not the only option, but I would say it's the easiest. - -- Kyle Powell | Red Hat | Senior Consultant, RHCE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFJPvK27pTtanQdBU4RAmutAJ49VZ42VPngzP4TkMT/64NV6VfX1wCfbaN+ caiMf+4Yyyfqk2b47xv9IpE= =SzGR -----END PGP SIGNATURE----- From atodorov at redhat.com Thu Dec 11 17:58:20 2008 From: atodorov at redhat.com (Alexander Todorov) Date: Thu, 11 Dec 2008 19:58:20 +0200 Subject: [PATCH] Add --root-device to upgrade command Message-ID: <494154BC.4030701@redhat.com> Hi all, the attached patch adds new option to the upgrade command in kickstart. upgrade [--root-device=/dev/sda2] The purpose is to be able to automatically upgrade systems that are dual boot. Specifying which is the root device makes upgrades more flexible. More info is available at anaconda-devel-list: https://www.redhat.com/archives/anaconda-devel-list/2008-December/msg00162.html Thanks, Alexander. -------------- next part -------------- A non-text attachment was scrubbed... Name: pykickstart_upgrade.patch Type: text/x-patch Size: 2046 bytes Desc: not available URL: From clumens at redhat.com Thu Dec 11 18:53:01 2008 From: clumens at redhat.com (Chris Lumens) Date: Thu, 11 Dec 2008 13:53:01 -0500 Subject: [PATCH] Add --root-device to upgrade command In-Reply-To: <494154BC.4030701@redhat.com> References: <494154BC.4030701@redhat.com> Message-ID: <20081211185301.GD27793@localhost.localdomain> > the attached patch adds new option to the > upgrade command in kickstart. > > upgrade [--root-device=/dev/sda2] > > The purpose is to be able to automatically upgrade systems that are dual boot. > Specifying which is the root device makes upgrades more flexible. > > More info is available at anaconda-devel-list: > https://www.redhat.com/archives/anaconda-devel-list/2008-December/msg00162.html Note that we do actually have a bug number for this - 471232. > diff --git a/pykickstart/commands/upgrade.py b/pykickstart/commands/upgrade.py > index b7dba86..8510fbe 100644 > --- a/pykickstart/commands/upgrade.py > +++ b/pykickstart/commands/upgrade.py > @@ -30,20 +30,37 @@ class FC3_Upgrade(KickstartCommand): > > def __init__(self, writePriority=0, *args, **kwargs): > KickstartCommand.__init__(self, writePriority, *args, **kwargs) > + self.op = self._getParser() > + > self.upgrade = kwargs.get("upgrade", None) > + self.root_device = kwargs.get("root_device", None) > > def __str__(self): > if self.upgrade is None: > - return "" > + retval="" > > if self.upgrade: > - return "# Upgrade existing installation\nupgrade\n" > + if (self.root_device is not None): > + retval="# Upgrade existing installation\nupgrade --root-device=%s\n" % self.root_device > + else: > + retval="# Upgrade existing installation\nupgrade\n" > else: > - return "# Install OS instead of upgrade\ninstall\n" > + retval="# Install OS instead of upgrade\ninstall\n" > + > + return retval > + > + def _getParser(self): > + op = KSOptionParser(lineno=self.lineno) > + op.add_option("--root-device", dest="root_device") > + return op > > def parse(self, args): > - if len(args) > 0: > - raise KickstartValueError, formatErrorMsg(self.lineno, msg=_("Kickstart command %s does not take any arguments") % "upgrade") > + (opts, extra) = self.op.parse_args(args=args) > + > + if (opts.root_device is not None) and (opts.root_device == ""): > + raise KickstartValueError, formatErrorMsg(self.lineno, msg=_("Kickstart command %s does not accept empty parameter %s") % ("upgrade", "--root-device")) > + else: > + self.root_device = opts.root_device > > if self.currentCmd == "upgrade": > self.upgrade = True > Thanks for fetching pykickstart first and following all my recent stylistic changes (like the kwargs.get stuff)! However, you don't want to add this option to FC3_Upgrade. You'll want to make a new F11_Upgrade object that inherits from FC3_Upgrade, then modify the appropriate commandMap entry in handlers/control.py to reference the F11_Upgrade object. Then the F11_Upgrade class gets the new option and the FC3_Upgrade class goes untouched. Before you can do that, I will need to add support for F11 throughout, which will only take a second. I'll do that just as soon as I send this mail. Aside from that one comment, I'm happy with the name of the parameter and how you've implemented it. I'm sure a second run of the patch with the new class will be fine. - Chris From atodorov at redhat.com Fri Dec 12 09:34:55 2008 From: atodorov at redhat.com (Alexander Todorov) Date: Fri, 12 Dec 2008 11:34:55 +0200 Subject: [PATCH] Add --root-device to upgrade command In-Reply-To: <20081211185301.GD27793@localhost.localdomain> References: <494154BC.4030701@redhat.com> <20081211185301.GD27793@localhost.localdomain> Message-ID: <4942303F.3040402@redhat.com> Chris Lumens wrote: > Thanks for fetching pykickstart first and following all my recent > stylistic changes (like the kwargs.get stuff)! > > However, you don't want to add this option to FC3_Upgrade. You'll want > to make a new F11_Upgrade object that inherits from FC3_Upgrade, then > modify the appropriate commandMap entry in handlers/control.py to > reference the F11_Upgrade object. Then the F11_Upgrade class gets the > new option and the FC3_Upgrade class goes untouched. > I don't fully understand the reasoning behind this because the new features are backwards compatible. Anyway I've moved them into a separate class and updated the control map. I only don't understand what's the purpose of: removedKeywords = KickstartCommand.removedKeywords removedAttrs = KickstartCommand.removedAttrs in FC3_Upgrade (and other classes) and not sure if I need it in the new class. Btw as pointed in anaconda-devel-list it will be necessary to support UUID and LABEL when specifying the device but the pykickstart bits don't need to change. Just change synopsis to: upgrade [--root-device=DEV] where DEV=/dev/sda1 or DEV=UUID=abcd-fdeb-.... or DEV=LABEL=/ This is consistent with /etc/fstab and other places and the calling application (Anaconda) will need to take care of finding the correct device. Regards, Alexander. -------------- next part -------------- A non-text attachment was scrubbed... Name: pykickstart_upgrade.patch Type: text/x-patch Size: 2601 bytes Desc: not available URL: From jlaska at redhat.com Fri Dec 12 13:46:09 2008 From: jlaska at redhat.com (James Laska) Date: Fri, 12 Dec 2008 08:46:09 -0500 Subject: [PATCH] Add --root-device to upgrade command In-Reply-To: <4942303F.3040402@redhat.com> References: <494154BC.4030701@redhat.com> <20081211185301.GD27793@localhost.localdomain> <4942303F.3040402@redhat.com> Message-ID: <1229089569.19977.13.camel@localhost.localdomain> On Fri, 2008-12-12 at 11:34 +0200, Alexander Todorov wrote: > I only don't understand what's the purpose of: > > removedKeywords = KickstartCommand.removedKeywords > removedAttrs = KickstartCommand.removedAttrs Some commands have attributes that are no longer supported. A good example is the 'vnc' command (others are "xconfig --resolution", "part --bytes-per-inode" etc..) Current kickstart grammar supports: * vnc [--host=] [--port=] [--password=] While older grammar supported (FC3 era): * vnc [--enabled] [--connect=[:]] [--password=] The removedAttrs allows us to define subclasses that deprecate or remove previous attributes. Hope that helps! Thanks, James -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From atodorov at redhat.com Fri Dec 12 14:19:58 2008 From: atodorov at redhat.com (Alexander Todorov) Date: Fri, 12 Dec 2008 16:19:58 +0200 Subject: [PATCH] Add --root-device to upgrade command In-Reply-To: <1229089569.19977.13.camel@localhost.localdomain> References: <494154BC.4030701@redhat.com> <20081211185301.GD27793@localhost.localdomain> <4942303F.3040402@redhat.com> <1229089569.19977.13.camel@localhost.localdomain> Message-ID: <4942730E.5010900@redhat.com> James Laska wrote: > The removedAttrs allows us to define subclasses that deprecate or remove > previous attributes. > > Hope that helps! Good explanation but I'm still not sure if I need this in the F11_Upgrade class which derives from the FC3_Upgrade class and only adds to it but doesn't remove. I think I'm save with the patch but would like to hear from Chris Lumens if he's OK with it as well. -- Alexander. From clumens at redhat.com Fri Dec 12 14:37:20 2008 From: clumens at redhat.com (Chris Lumens) Date: Fri, 12 Dec 2008 09:37:20 -0500 Subject: [PATCH] Add --root-device to upgrade command In-Reply-To: <4942303F.3040402@redhat.com> References: <494154BC.4030701@redhat.com> <20081211185301.GD27793@localhost.localdomain> <4942303F.3040402@redhat.com> Message-ID: <20081212143719.GH27793@localhost.localdomain> > I don't fully understand the reasoning behind this because the new > features are backwards compatible. Anyway I've moved them into a separate > class and updated the control map. The reason you want a completely new class is because FC3-F10 did not support this option. We don't want to recognize it as valid when we parse kickstart versions for those releases. If someone's doing a RHEL5 install test and uses a kickstart file they just copied from their rawhide system, we want to make sure we give them an error. > I only don't understand what's the purpose of: > > removedKeywords = KickstartCommand.removedKeywords > removedAttrs = KickstartCommand.removedAttrs > > > in FC3_Upgrade (and other classes) and not sure if I need it in the new class. James explained these already. While you don't need them since we've never removed any attributes or options from the upgrade command, I like to see them in each class so that all objects have these attributes. That way the BaseCommand and BaseData objects can just assume they're present. > pykickstart/commands/upgrade.py | 33 +++++++++++++++++++++++++++++++++ > pykickstart/handlers/control.py | 4 ++-- > 2 files changed, 35 insertions(+), 2 deletions(-) > > diff --git a/pykickstart/commands/upgrade.py b/pykickstart/commands/upgrade.py > index b7dba86..5fbf93a 100644 > --- a/pykickstart/commands/upgrade.py > +++ b/pykickstart/commands/upgrade.py > @@ -49,3 +49,36 @@ class FC3_Upgrade(KickstartCommand): > self.upgrade = True > else: > self.upgrade = False > + > +class F11_Upgrade(FC3_Upgrade): Please do add: removedKeywords = FC3_Upgrade.removedKeywords removedAttrs = FC3_Upgrade.removedAttrs here as class attributes. Subclasses do not inherit class attributes of their superclass (at least, they didn't in my testing) so we have to set these explicitly. > + def __init__(self, writePriority=0, *args, **kwargs): > + FC3_Upgrade.__init__(self, writePriority, *args, **kwargs) > + > + self.op = self._getParser() > + self.root_device = kwargs.get("root_device", None) > + > + def __str__(self): > + if self.upgrade and (self.root_device is not None): > + retval="# Upgrade existing installation\nupgrade --root-device=%s\n" % self.root_device > + else: > + retval=FC3_Upgrade.__str(self)__ You meant retval = FC3_Upgrade.__str__(self) here, I'm sure. > + > + return retval > + > + def _getParser(self): > + op = KSOptionParser(lineno=self.lineno) > + op.add_option("--root-device", dest="root_device") > + return op Instead of calling KSOptionParser, call FC3_Upgrade._getParser(self) here to pull in whatever arguments FC3_Upgrade's KSOptionParser object may support. I know it's none in this case, but that's how it works in every other class in pykickstart and I really like things to be consistent. Everything else looks fine to me. - Chris From atodorov at redhat.com Fri Dec 12 16:15:54 2008 From: atodorov at redhat.com (Alexander Todorov) Date: Fri, 12 Dec 2008 18:15:54 +0200 Subject: [PATCH] Add --root-device to upgrade command In-Reply-To: <20081212143719.GH27793@localhost.localdomain> References: <494154BC.4030701@redhat.com> <20081211185301.GD27793@localhost.localdomain> <4942303F.3040402@redhat.com> <20081212143719.GH27793@localhost.localdomain> Message-ID: <49428E3A.1090300@redhat.com> Chris Lumens wrote: >> + def _getParser(self): >> + op = KSOptionParser(lineno=self.lineno) >> + op.add_option("--root-device", dest="root_device") >> + return op > > Instead of calling KSOptionParser, call FC3_Upgrade._getParser(self) > here to pull in whatever arguments FC3_Upgrade's KSOptionParser object > may support. I know it's none in this case, but that's how it works in > every other class in pykickstart and I really like things to be > consistent. > See F9_Autopart vs. FC3_Autopart. Same case as with upgrades. The base class doesn't define _getParser and the derived class calls KSOptionParser directly instead of calling _getParser from the base class. This will break when the base class doesn't define _getParser. Attached patch with all other issues resolved except the _getParser change. -- Alexander. -------------- next part -------------- A non-text attachment was scrubbed... Name: pykickstart_upgrade.patch Type: text/x-patch Size: 2702 bytes Desc: not available URL: From clumens at redhat.com Fri Dec 12 16:34:36 2008 From: clumens at redhat.com (Chris Lumens) Date: Fri, 12 Dec 2008 11:34:36 -0500 Subject: [PATCH] Add --root-device to upgrade command In-Reply-To: <49428E3A.1090300@redhat.com> References: <494154BC.4030701@redhat.com> <20081211185301.GD27793@localhost.localdomain> <4942303F.3040402@redhat.com> <20081212143719.GH27793@localhost.localdomain> <49428E3A.1090300@redhat.com> Message-ID: <20081212163435.GI27793@localhost.localdomain> > See F9_Autopart vs. FC3_Autopart. Same case as with upgrades. The base > class doesn't define _getParser and the derived class calls > KSOptionParser directly instead of calling _getParser from the base > class. This will break when the base class doesn't define _getParser. Oh yes of course. Then in that case, it looks fine to me. Once someone comments on the anaconda portion (which could also be me here in a minute), I'll commit to pykickstart. Thanks for the patch. - Chris From kernel at linuxace.com Wed Dec 17 18:40:41 2008 From: kernel at linuxace.com (Phil Oester) Date: Wed, 17 Dec 2008 10:40:41 -0800 Subject: Kickstart via ks=hd not working Message-ID: <20081217184041.GA15283@linuxace.com> When using ks=hd: on the command line, I get an error that the ks.cfg file can't be found, but if I hit enter on the same path, it works the second time. It seems to be due to the scsi drives not yet being ready when kickstart first looks for the file. >From the logs: 17:03:35 DEBUG : probing buses 17:03:35 DEBUG : waiting for hardware to initialize 17:03:37 INFO : getting kickstart file 17:03:37 INFO : getting kickstart file from harddrive 17:03:37 INFO : Loading ks from device sda1 on path /ks/ks.cfg 17:03:37 INFO : getFileFromBlockDevice(sda1, /ks/ks.cfg) 17:03:37 ERROR : failed to mount /dev/sda1: No such file or directory 17:05:56 INFO : getting kickstart file from harddrive 17:05:56 INFO : Loading ks from device sda1 on path /ks/ks.cfg 17:05:56 INFO : getFileFromBlockDevice(sda1, /ks/ks.cfg) 17:05:56 INFO : Searching for file on path /tmp/mnt//ks/ks.cfg 17:05:56 INFO : file copied to /tmp/ks.cfg Any ideas? Some need for scsi_wait_scan here perhaps? Phil From kpowell at redhat.com Wed Dec 17 20:30:55 2008 From: kpowell at redhat.com (Kyle Powell) Date: Wed, 17 Dec 2008 15:30:55 -0500 Subject: Kickstart via ks=hd not working In-Reply-To: <20081217184041.GA15283@linuxace.com> References: <20081217184041.GA15283@linuxace.com> Message-ID: <4949617F.9040606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phil Oester wrote: > When using ks=hd: on the command line, I get an error that the ks.cfg > file can't be found, but if I hit enter on the same path, it works the > second time. It seems to be due to the scsi drives not yet being ready > when kickstart first looks for the file. > >>From the logs: > > 17:03:35 DEBUG : probing buses > 17:03:35 DEBUG : waiting for hardware to initialize > 17:03:37 INFO : getting kickstart file > 17:03:37 INFO : getting kickstart file from harddrive > 17:03:37 INFO : Loading ks from device sda1 on path /ks/ks.cfg > 17:03:37 INFO : getFileFromBlockDevice(sda1, /ks/ks.cfg) > 17:03:37 ERROR : failed to mount /dev/sda1: No such file or directory > > 17:05:56 INFO : getting kickstart file from harddrive > 17:05:56 INFO : Loading ks from device sda1 on path /ks/ks.cfg > 17:05:56 INFO : getFileFromBlockDevice(sda1, /ks/ks.cfg) > 17:05:56 INFO : Searching for file on path /tmp/mnt//ks/ks.cfg > 17:05:56 INFO : file copied to /tmp/ks.cfg > > Any ideas? Some need for scsi_wait_scan here perhaps? > > Phil Looks like a bug, but not necessarily in anaconda. Shouldn't the drive be ready before POST completes? Perhaps you have a BIOS option enabled that tells POST to complete even though the drive isn't ready (fast POST or something like that)? I'm unable to duplicate this on my hardware. I don't know of any parameters that would tell anaconda to wait. The only thing I can think of is passing multiple (MANY!) duplicate ks parameters. Anaconda will try them all (well, I've only tried it with < 4 so there may be a limit, and I've never tried passing multiple ks parameters with the same value either). So you could try: ks=hd:sda1:/ks/ks.cfg ks=hd:sda1:/ks/ks.cfg ... ks=hd:sda1:/ks/ks.cfg and see if the drive becomes ready before anaconda reaches the end of the list. I know that's far from elegant, but it's the best I can come up with. - -- Kyle Powell | Red Hat | Senior Consultant, RHCE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFJSWF/7pTtanQdBU4RAh30AKCOMvDP8rN8dex5EtKBBTPsXGVbSACfWvtl Xm1Nz41iCO1g1l/ynTzUdnc= =UVuy -----END PGP SIGNATURE----- From kernel at linuxace.com Wed Dec 17 22:04:12 2008 From: kernel at linuxace.com (Phil Oester) Date: Wed, 17 Dec 2008 14:04:12 -0800 Subject: Kickstart via ks=hd not working In-Reply-To: <4949617F.9040606@redhat.com> References: <20081217184041.GA15283@linuxace.com> <4949617F.9040606@redhat.com> Message-ID: <20081217220412.GA17614@linuxace.com> On Wed, Dec 17, 2008 at 03:30:55PM -0500, Kyle Powell wrote: > Phil Oester wrote: > > When using ks=hd: on the command line, I get an error that the ks.cfg > > file can't be found, but if I hit enter on the same path, it works the > > second time. It seems to be due to the scsi drives not yet being ready > > when kickstart first looks for the file. > > Looks like a bug, but not necessarily in anaconda. Shouldn't the drive be ready > before POST completes? Perhaps you have a BIOS option enabled that tells POST to > complete even though the drive isn't ready (fast POST or something like that)? > I'm unable to duplicate this on my hardware. I don't know of any parameters that > would tell anaconda to wait. The only thing I can think of is passing multiple > (MANY!) duplicate ks parameters. Anaconda will try them all (well, I've only > tried it with < 4 so there may be a limit, and I've never tried passing multiple > ks parameters with the same value either). So you could try: > > ks=hd:sda1:/ks/ks.cfg ks=hd:sda1:/ks/ks.cfg ... ks=hd:sda1:/ks/ks.cfg > > and see if the drive becomes ready before anaconda reaches the end of the list. > I know that's far from elegant, but it's the best I can come up with. That didn't work, but I found a solution. The problem is that Fedora kernels now set SCSI_SCAN_ASYNC=y, so there isn't enough time in the boot process for these RAID disks to come up. I simply added "scsi_mod.scan=sync" to the kernel command line to override the ASYNC, and it worked fine. Phil From mdehaan at redhat.com Fri Dec 19 03:04:08 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 18 Dec 2008 22:04:08 -0500 Subject: Anaconda error In-Reply-To: <493D8E93.6040000@fiber-hosting.com> References: <493D8E93.6040000@fiber-hosting.com> Message-ID: <494B0F28.5000407@redhat.com> Andrew wrote: > Hello, > > I keep getting an error while trying to install any version of Fedora > with cobbler. While using dhcp or trying to manually set the IP > Anaconda says cannot set IP and the install errors out. You have "network --bootproto=dhcp --device=eth1 --onboot=on" Which seems to be you're not setting up eth0 at this time. What do you have on the kernel options line? --Michael > > Here is my kickstart from my Fedora 9 profile: > > # kickstart template for Fedora 8 and later. > # (includes %end blocks) > # do not use with earlier distros > > #platform=x86, AMD64, or Intel EM64T > # System authorization information > auth --useshadow --enablemd5 > # System bootloader configuration > bootloader --location=mbr > # Partition clearing information > clearpart --all --initlabel > # Use text mode install > text > # Firewall configuration > firewall --enabled > # Run the Setup Agent on first boot > firstboot --disable > # System keyboard > keyboard us > # System language > lang en_US > # Use network installation > url --url=http://192.168.100.18/cblr/links/Fedora9-i386 > # If any cobbler repo definitions were referenced in the kickstart > profile, include them here. > repo --name=source-1 > --baseurl=http://192.168.100.18/cobbler/ks_mirror/Fedora9/os > > # Network information > network --bootproto=dhcp --device=eth1 --onboot=on > # Reboot after installation > reboot > > # SELinux configuration > selinux --disabled > # Do not configure the X Window System > skipx > # System timezone > timezone America/New_York > # Install OS instead of upgrade > install > # Clear the Master Boot Record > zerombr > > # Magically figure out how to partition this thing > %include /tmp/partinfo > > > > %pre > # Determine how many drives we have > set $(list-harddrives) > let numd=$#/2 > d1=$1 > d2=$3 > > cat << EOF > /tmp/partinfo > part / --fstype ext3 --size=1024 --grow --ondisk=$d1 --asprimary > part swap --size=1024 --ondisk=$d1 --asprimary > EOF > > > > wget > "http://192.168.100.18/cblr/svc/op/trig/mode/pre/profile/Fedora9-i386" > -O /dev/null > %end > > %packages > %end > > %post > > > > > wget "http://192.168.100.18/cblr/svc/op/ks/profile/Fedora9-i386" -O > /root/cobbler.ks > wget > "http://192.168.100.18/cblr/svc/op/trig/mode/post/profile/Fedora9-i386" > -O /dev/null > %end > > > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list From mdehaan at redhat.com Fri Dec 19 03:05:28 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 18 Dec 2008 22:05:28 -0500 Subject: Anaconda updates= boot option In-Reply-To: <727e50150812091352n39752b3el567a33f05063039@mail.gmail.com> References: <727e50150812091352n39752b3el567a33f05063039@mail.gmail.com> Message-ID: <494B0F78.1080802@redhat.com> Aaron Cohen wrote: > I'm trying to configure PXE booting at the moment, and I've got it > mostly working, except for the updates= option. > > Is this meant to configure a server that RPM updates are pulled from > during installation or is it more limited than that? > > I have it specified as a local yum repository, and it does not seem to > be used at all, only my http: (which I specified using > method=) is being used. > > Is the only option to create a kickstart file that adds my repository? > > This seems to be for both Fedora 9 and 10. > > Thanks, > Aaron > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > Anaconda for EL 5 and later (and any recent Fedora) has a "repo" directive to attach to additional yum repositories during installation. If you're using Cobbler, it will configure these for you for repositories you have mirrored and attached to particular profiles, so that may be of interest. Either way "repo" is what you want. --Michael From masaiah.p at gmail.com Mon Dec 22 03:16:59 2008 From: masaiah.p at gmail.com (Masaiah) Date: 22 Dec 2008 03:16:59 -0000 Subject: Masaiah invites you to join Zorpia Message-ID: <20081222031659.26515.qmail@zorpia.com> Hi Discussion list about! Your friend Masaiah from , just invited you to his online photo albums and journals at Zorpia.com. So what is Zorpia? It is an online community that allows you to upload unlimited amount of photos, write journals and make friends. We also have a variety of skins in store for you so that you can customize your homepage freely. Join now for free! Please click the following link to join Zorpia: http://signup.zorpia.com/signup?invitation_key=20081273560f58f7bdb25e3c409baad3&referral=masaiah&tt=5&hour=2008122122&sub=1 This message was delivered with the Masaiah's initiation. If you wish to discontinue receiving invitations from us, please click the following link: http://signup.zorpia.com/email/optout/kickstart-list at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: