koan --replace-self and embedding the kernel in the initrd
by Michael DeHaan
It seems that --replace-self is not working so well for F10 install
targets. (Anaconda doesn't find the embedded kickstart).
I'm proposing we add the new flag to koan "--embed-kickstart" to embed
the kickstart in the initrd, and make not embedding the kickstart the
default behavior. When not sent, koan
will just add the "ks=http://..." line as usual to the kickstart line,
which is exactly what happens with PXE.
This behavior is needed for some libdhcp/pump timeout scenarios only --
in most cases with reliable dhcp it's not needed, nor could PXE install
bases take advantage of this anyway.
--Michael
15 years, 4 months
Re: devel build problem
by Kevin James
Thanks for the quick response. Checked the site-packages directories and
turns out I was building on x86_64 and installing on i586. An i586
platform won't look in /usr/lib64/site-packages for modules :)
Cheers,
KEv.
On Wed, 2009-01-07 at 10:32 -0500, Michael DeHaan wrote:
> Kevin James wrote:
> > Hi all,
> >
> > Is it just me or is anyone else seeing this problem with the devel
> > branch?
> >
> > Builds rpm fine, but when I install and run "cobbler check" I get:
> >
> > Traceback (most recent call last):
> > File "/usr/bin/cobbler", line 17, in ?
> > import cobbler.cobbler as app
> > ImportError: No module named cobbler.cobbler
> >
> > Cheers,
> > KEv.
> >
> >
> >
> I'm not ....
>
> This could happen if you (force?) installed an RPM built on one OS onto
> another that had a different version of Python.
> The module would end up in site-packages/python2.5 instead of 2.4, etc.
>
> --Michael
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
--
Kevin James
Applied Technology Senior Strategist
Novell Global Enablement
------------------------
Novell, Inc.
http://www.novell.com
15 years, 4 months
devel build problem
by Kevin James
Hi all,
Is it just me or is anyone else seeing this problem with the devel
branch?
Builds rpm fine, but when I install and run "cobbler check" I get:
Traceback (most recent call last):
File "/usr/bin/cobbler", line 17, in ?
import cobbler.cobbler as app
ImportError: No module named cobbler.cobbler
Cheers,
KEv.
--
Kevin James
Applied Technology Senior Strategist
Novell Global Enablement
------------------------
Novell, Inc.
http://www.novell.com
15 years, 4 months
Addition of .gitignore and minor cleanup of Makefile
by James Laska
Greetings,
I'm a big fan of using `git status` to determine the state of my local git repository. The following patch adds a .gitignore file to ignore any files or directories built during the cobbler build process. This includes rpm-build/, dist/, *.pyc files etc... Now `git status` will show you what local changes haven't yet been commited, excluding *.pyc, tmp files, and other cobbler `make` created files.
In addition to the .gitignore, a very minor change was made to the Makefile. I'm not sure if the 'rpms' target was intended as the default build target, but I'm more famililar having just a 'build' target which does any pre-processing and docs generation prior to `python setup.py sdist`.
Comments appreciated.
Thanks,
James
15 years, 4 months
[PATCH] Added COPYING and README file for yaboot as requested by Paul Nasrat.
by James Laska
---
loaders/COPYING.yaboot | 15 +++
loaders/README.yaboot | 271 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 286 insertions(+), 0 deletions(-)
create mode 100644 loaders/COPYING.yaboot
create mode 100644 loaders/README.yaboot
diff --git a/loaders/COPYING.yaboot b/loaders/COPYING.yaboot
new file mode 100644
index 0000000..7a072bb
--- /dev/null
+++ b/loaders/COPYING.yaboot
@@ -0,0 +1,15 @@
+Cobbler deploys a yaboot binary over TFTP to enable network booting of PowerPC
+machines.
+
+Yaboot is GPL and is being distributed in binary form persuant to this section
+of the GPL license:
+
+ c) Accompany it with the information you received as to the offer
+ to distribute corresponding source code. (This alternative is
+ allowed only for noncommercial distribution and only if you
+ received the program in object code or executable form with such
+ an offer, in accord with Subsection b above.)
+
+Source code to yaboot is available on http://yaboot.ozlabs.org.
+
+A full copy of the GPL is available in "COPYING".
diff --git a/loaders/README.yaboot b/loaders/README.yaboot
new file mode 100644
index 0000000..e619eb5
--- /dev/null
+++ b/loaders/README.yaboot
@@ -0,0 +1,271 @@
+Yaboot -- PowerPC GNU/Linux OpenFirmware bootloader
+-------------------------------------------------------------------
+
+Please read the "COPYING" file for licence informations.
+
+-------------------------------------------------------------------
+
+Yaboot is an OpenFirmware bootloader for Open Firmware based
+machines. It is known to work on "NewWorld" class powermacs (iMac and
+all machines released after it), RS/6000, and possibly other OF based
+CHRP machines. "OldWorld" PowerMacs (with the built-in MacOS ROM)
+are not supported.
+
+This README serves as a quick-start introduction to yaboot and its
+installation utilities. For a more complete usage and installation
+guide, see yaboot-howto.html/index.en.html in the same folder where
+this README is located, or else inside the doc folder in this
+directory. For documentation about all the options available, see the
+man pages (bootstrap, yaboot, yaboot.conf, ybin, mkofboot, ofpath,
+yabootconfig).
+
+Mailing lists
+-------------------------------------------------------------------
+The following mailing lists exist for yaboot:
+
+yaboot-users User related questions/discussion regarding yaboot
+yaboot-devel Technical and development discussion regarding yaboot
+
+Please see https://ozlabs.org/mailman/listinfo/LISTNAME where LISTNAME is one
+of the above named lists.
+
+http://yaboot.ozlabs.org/
+
+-------------------------------------------------------------------
+Bootloader Installation Utilities
+ybin, mkofboot, ofpath, yabootconfig
+Written by Ethan Benson <erbenson(a)alaska.net>
+-------------------------------------------------------------------
+
+ybin (YaBoot INstaller) and mkofboot
+-------------------------------------------------------------------
+
+ybin is a lilo/quik style bootloader installer for PowerPC based
+machines which require a bootstrap partition rather than a traditional
+bootblock (i.e. all `NewWorld' Macintoshes). When ybin is configured
+correctly you can simply type ybin at the command line as root, and
+the bootloader and its configuration file will be installed or updated
+on the bootstrap partition without any further user intervention.
+
+ybin also supports IBM PowerPC hardware which requires a slightly different
+bootstrap partition setup. For these machines, ybin uses dd to write yaboot
+directly to the partition instead of copying it to a filesystem on the
+partition. ybin will add the requisite .note section to yaboot prior to
+installation (IBM CHRP only).
+
+mkofboot is a companion script (actually a symlink to ybin) which
+initializes the bootstrap partition prior to running ybin to install
+the bootloader on it. mkofboot will confirm you want to continue
+before proceeding unless called with the -f or --force switch. This
+is in contrast to ybin, which is non destructive except that it
+overwrites any existing yaboot files (yaboot and yaboot.conf) at the
+root level of the bootstrap filesystem.
+
+mkofboot and ybin both refer to the same configuration file (normally
+yaboot.conf) to determine where the bootstrap files will be placed.
+
+IMPORTANT: The bootstrap partition should never be mounted anywhere on
+your filesystem, ybin and mkofboot will check if it is and refuse to
+operate on it if it is mounted. It is not necessary to keep anything
+but the boot loader on the bootstrap partition, yaboot will load the
+kernel from your root partition (which can be an ext2/3, XFS, or
+ReiserFS filesystem). Do not mount the bootstrap partition on top of
+/boot.
+
+ybin can update a bootstrap filesystem either on a block device or in
+an ordinary file (as in an image of a filesystem.)
+
+NOTE: You must have a secure mktemp program otherwise ybin will be
+vulnerable to race conditions. Debian's mktemp qualifies I don't know
+about the other distributions, you have been warned. The temp file is
+created in /tmp by default but ybin will respect the $TMPDIR
+environment variable.
+
+
+ofpath
+-------------------------------------------------------------------
+
+The included ofpath utility can usually determine the OpenFirmware
+device path that corresponds with a unix device node in /dev/. Ybin
+uses this utility to find the path to the bootstrap partition and to
+any defined macos/macosx partitions. ofpath is based on the utility
+`show_of_path.sh' written by Olaf Hering.
+
+
+NOTE: ofpath may not work with all SCSI cards/drivers.
+
+IMPORTANT: ofpath will NOT work on NewWorld Powermacs if the machine
+was booted with BootX.
+
+
+yabootconfig
+-------------------------------------------------------------------
+
+Yabootconfig creates a default configuration file and then runs mkofboot to
+complete the bootloader installation. yabootconfig reads the running
+system's /etc/fstab to determine the kernel location, and detects the
+location of the 800k Apple_Bootstrap partition. It will also find IBM
+CHRP bootstrap partitions (type 0x41 PReP Boot).
+
+
+
+Yaboot.conf Configuration File
+-------------------------------------------------------------------
+
+yaboot.conf configuration file settings are covered in detail in `man
+yaboot.conf'. Avoid the use of spaces in the config file, except in
+comment lines or inside quotes. Here are the essential settings.
+
+
+boot=
+Example: boot=/dev/hda2
+
+This required setting defines the bootstrap partition device. It can
+also be a regular file if you are creating a filesystem image for some
+reason. The default config file has this set to ``unconfigured'' which
+will cause ybin to complain about you not reading the docs, it is the
+only option you should need to change for ybin to work. Be sure you
+include the partition number at the end, it should never be something
+like /dev/hda.
+
+
+install=
+Example: install=/usr/lib/yaboot/yaboot or /usr/local/lib/yaboot/yaboot
+
+The full pathname to the yaboot OpenFirmware executable file. The
+default is shown above. This file will be copied to the root level of
+the bootstrap partition. Note: If you are installing an alternative
+bootloader, its filename will be changed to yaboot when it is copied
+(to match what the first stage bootloader expects to be loading).
+
+
+partition=
+Example: partition=3
+
+The partition number on which the kernel image is located. By default,
+this partition is assumed to be on the same device from which yaboot
+was loaded. If needed, device= can be used to explicitly specify the
+device.
+
+
+image=
+Examples: image=/vmlinux or image=/boot/vmlinux-2.2.19-pmac
+
+The path to the image from the root level of the partition (remember
+that yaboot is unaware of mountpoints). Don't forget to include the
+leading slash when specifying the image path (image=vmlinux will
+probably fail).
+
+
+root=
+Example: root=/dev/hda3
+
+The Linux device name for the root partition. This parameter is
+passed to the kernel when it starts up to let it know where its root
+filesystem is located. Refer to the yaboot.conf man page for details
+on kernel image options such as append=, initrd=, and initrd-size=.
+
+
+magicboot= (same as -m or --magicboot)
+Example: /usr/local/lib/yaboot/ofboot
+
+Identifies the first stage loader. The example shown is the default. The
+ofboot script it refers to is included with and configured automatically by
+ybin from options in /etc/yaboot.conf. The magicboot= can be the full
+pathname to any OF CHRP script file. Since some newer OpenFirmware
+implementations appear to require a CHRP script, the magicboot= setting is
+highly recommended. If you don't include magicboot=, then yaboot itself will
+be the active bootfile. magicboot= cannot be used on IBM CHRP.
+
+
+Boot Menu Options
+-------------------------------------------------------------------
+
+The following options work only if you have specified the magicboot= option.
+Each option specifies an OpenFirmware or unix device path to another
+operating system's boot partition. When you define one of these options you
+will be presented with a simple menu at bootup allowing you to hit `l' to
+boot GNU/Linux or another letter to boot the other OS (see below). These
+letters are typed without a shift key (the boot menu is case sensitive).
+When set to a unix device node such as /dev/hda11 then ybin will use the
+ofpath utility to determine the OpenFirmware device path.
+
+ Option Letter Operating System Type
+ --------- ------ ---------------------------------------------
+ bsd= b NetBSD or OpenBSD root partition (you must
+ have the BSD ofwboot bootloader
+ installed at /usr/local/lib/yaboot/ofwboot)
+
+ macos= m MacOS 8.* or 9.* bootable partition
+
+ macosx= x MacOS X boot partition (also see brokenosx)
+
+ darwin= d Darwin boot partition
+
+ enablecdboot c Boot from the CDROM drive
+
+ enablenetboot n Boot from the network
+
+ enableofboot o Display an OpenFirmware prompt
+
+ defaultos= The default OS to load (linux, bsd, macos,
+ darwin or macosx.
+
+brokenosx
+
+This option causes the menu entry for MacOSX to execute
+\System\Library\CoreServices\BootX from the macosx=device instead of
+the usual \\:tbxi. This is necessary if OSX is installed onto an HFS+
+filesystem instead of UFS. When OSX is installed on an HFS+ filesystem
+MacOS will mount and debless the OSX partition. Add this option if
+the OSX menu entry breaks after booting MacOS. You should not use
+this option if OSX is installed on a UFS filesystem, for UFS installs
+you specify the OSX bootstrap partition which is protected against
+MacOS.
+
+delay=
+Example: delay=5
+
+The time in seconds that the first stage ofboot loader will wait for
+you to choose a letter before booting the default OS defined in
+defaultos=. If not set, the value of timeout= (converted to seconds)
+will be used.
+
+
+Colors
+-------------------------------------------------------------------
+
+fgcolor=string
+
+Specifies the foreground (text) color used by yaboot and the
+multiboot menu. Available colors are: black, blue, light-blue, green,
+light-green, cyan, light-cyan, red, light-red, purple, light- purple,
+brown, light-gray, dark-gray, yellow, and white. The default is
+white.
+
+bgcolor=string
+
+Specifies the background color used by yaboot and the multiboot
+menu. Available colors are the same as fgcolor. The default is
+black.
+
+
+===========================================================================
+
+Copyright (C) 2000, 2001, 2002, 2003 Ethan Benson
+
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+as published by the Free Software Foundation; either version 2
+of the License, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+===========================================================================
--
1.6.0.4
15 years, 4 months
including the parents' kickstart file
by Axel Thimm
Hi,
anaconda has an %include directive, but that only works for local
files. The usual trick is to %pre a wget and %include it later on. But
that doesn't work if the parent kickstart file is the one defining the
base parameters like which URL to install from etc.
Also %including a prerendered kickstart file isn't really cobbler
style, the variables could have changed and the included rendered file
would reflect the old settings of the parent profile.
As a workaround I'm doing the following on top of every kickstart file:
#if $getVar("ksparent","") != ""
#include $ksparent
#end if
But ksparent needs to be provided and I'm using the poor man's API as
ksparent=`cobbler profile dumpvars --name=Parent | grep "^ 'kickstart':" | sed -e"s| 'kickstart': '\(.*\)',$|\1|"`
...
cobbler profile add [...] --inherit=Parent --ksmeta="ksparent=$ksparent" [...]
It would be nice if ksparent could be set automatically by cobbler and
if a simple scriplet like
$ cat /var/lib/cobbler/snippets/include_parent
#if $getVar("ksparent","") != ""
#include $ksparent
#end if
would be referenced on all sample kickstart files as
$SNIPPET('include_parent')
Thanks!
--
Axel.Thimm at ATrpms.net
15 years, 4 months
[PATCH] Allow import of RHEL 5 Client
by Hyclak, Matthew
Attached is a patch to allow imports of RHEL 5 Client in cobbler devel
Matt
--
Matt Hyclak
Systems and Operations
Office of Information Technology
Ohio University
(740) 593-1222
15 years, 4 months
issue with make devinstall
by Henry Kemp
I've just tried doing a 'git pull && make devinstall' and its failing
on copying 'webui_templates/system_netboot.tmpl' that's referenced in
setup.py but doesn't seem to exist in my git tree.
# git pull && make devinstall
[...snipped...]
copying webui_templates/empty.tmpl -> /usr/share/cobbler/webui_templates
copying webui_templates/blank.tmpl -> /usr/share/cobbler/webui_templates
copying webui_templates/enoaccess.tmpl -> /usr/share/cobbler/webui_templates
copying webui_templates/distro_list.tmpl ->
/usr/share/cobbler/webui_templates
copying webui_templates/distro_edit.tmpl ->
/usr/share/cobbler/webui_templates
copying webui_templates/profile_list.tmpl ->
/usr/share/cobbler/webui_templates
copying webui_templates/profile_edit.tmpl ->
/usr/share/cobbler/webui_templates
copying webui_templates/system_list.tmpl ->
/usr/share/cobbler/webui_templates
error: can't copy 'webui_templates/system_netboot.tmpl': doesn't exist
or not a regular file
make[1]: *** [install] Error 1
make[1]: Leaving directory `/root/cobbler'
make: *** [devinstall] Error 2
Thanks!
Henry
15 years, 4 months
SELinux/slow sync -- Moving "restorecon" logic out, plans for 1.4.1
by Michael DeHaan
It seems that Cobbler's usage of restorecon is also not only slow, but
it's also unneccessary.
Right now I think this is the cause of the "slow sync" problem.
So, my current plan, unless this turns out to /not/ work is:
(A) have cobbler check warn if the following semanage rules aren't
set, and tell the user to run them:
/usr/sbin/semanage fcontext -a -t public_content_t "/var/www/cobbler/images/.*"
/usr/sbin/semanage fcontext -a -t public_content_t "/var/lib/tftpboot/images/.*"
/usr/sbin/semanage fcontext -a -t public_content_t "/tftpboot/images/.*"
(B) Remove the logic in cobbler that calls restorecon, as copies should inherit the SELinux context of the directory in question. (Move's dont, but we don't use move).
This should speed up things considerably.
--Michael
15 years, 4 months
RE: Cobbler sync very slow, timing out with multiple interfaces
by Chris Weaver
Hi Michael,
In response to your response below: I do not have omapi enabled.
I tried removing every parameter from the bond interfaces, so the only
thing left was the interface field (named "bond0" and "bond1" for the
two interfaces). This made no difference, sync still timed out. So
it doesn't look like a problem with settings.
The only thing that works is removing all of the bond interfaces
entirely. So I have a workaround: I wrote a script that removes all
the bond interfaces from every server, then I run cobbler sync, then I
add all the bond interfaces back. This works but is obviously not a
great solution.
Also, the sync (without the bond interfaces) takes over 2 minutes. It
was taking around 24 seconds before, but I'm not sure what I changed
in the meantime, if anything.
>> It definitely has something to do with the bond interfaces. If I add
>> a system with 4 interfaces, sync takes about 6 seconds. If I add two
>> bond interfaces, the sync time goes to around 20 seconds. If I add a
>> second system with two bond interfaces, it times out (3 minutes). If
>> I remove those bond interfaces, it syncs in around 6 seconds again.
>> Note that I am not touching the slave interfaces, they are still
>> pointing to bond masters that no longer exist.
>>
>> If I add 7 systems with a total of 34 interfaces plus 14 bond
>> interfaces, the sync times out. If I remove all the bond interfaces
>> and try again, the sync takes about 24 seconds.
>>
>> I went into dhcp.template and removed all the cheetah stuff. It made
>> no difference at all, with one system or 7, bond interfaces or no. So
>> the long delays occur before cobbler starts working with the dhcp
>> template.
>>
>> Does anyone know what cobbler is doing at this point? What is
>> different in how it treats bond interfaces?
>>
>> FYI I'm on RHEL 4.6 x86_64. I brought in a newer syslinux (version
>> 3.72-2.el4.rf, the latest I could find). I went searching for a newer
>> syslinux because the cobbler docs recommend doing that. As I test I
>> went back to the syslinux version that came with RHEL 4.6 (version
>> 2.11-1) and it made no difference in the timing.
>>
>> For a while I had another version of syslinux but it caused a core
>> dump when cobbler tried to run gethostip. So I'm wondering if
>> syslinux is causing these long delays. What does cobbler sync use it for?
>>
>> --
>> ... Chris Weaver
>
>My first thought it to turn off omapi_enabled in /etc/cobbler/settings
>to see if this improves things -- OMAPI is rather buggy anyway and it
>could be sending more commands than needed with the new version. (I'm
>thinking complete removal of the feature, rather than deprecation, would
>be a good idea WRT OMAPI support).
>
>syslinux is used to supply our network bootloader mainly, of course.
>gethostip is also used to generate the filename segments in tftpboot,
>particularly for encoded IP's when a MAC is used as the boot criteria
>instead of the IP.
>
>I'm not sure why it would be slower when dealing with the bonded
>interfaces, though a copy of "cat
>/var/lib/cobbler/config/systems.d/$systemname" for one of the systems in
>question may help me better understand what the inputs might be.
>
>First though, let me know whether omapi is enabled or not. That may
>be choking on bad input, as everything else should just be restarting
>the service once.
>
>It could also be that another component cobbler uses was broken by a yum
>update.
>
>--Michael
--
... Chris Weaver
15 years, 4 months