Ubuntu installs using kickstart files
by Lars Kellogg-Stedman
I recently spent some time trying to move our existing Ubuntu
kickstart into Cobbler. I was unpleasantly surprised to discover that
given a distribution with breed=ubuntu, Cobbler uses kernel options
appropriate to a legacy Debian style install...and there's no way to
override this behavior without modifying the code, since all the logic
is inside pxegen.py rather than in the template.
I've solved the problem for now by lying to Cobbler and setting
breed=redhat, but this makes life difficult in other ways: in order to
use the same basic kickstart between our RHEL and Ubuntu installs I
need to have "breed-specific" directives in the kickstart (e.g., on
the Ubuntu side I need several "preseed" statements to get a hands-off
install). I can mess about with mgmt_classes or use separate
kickstart files, but it's not quite as clean.
I'm planning on taking a closer look at the template generation in
pxegen.py and possibly proposing some changes to how this works.
Before going too far down that particular path I wanted to see if
anyone else was working on something similar, or if anyone had
thoughts on this issue they'd like to share.
Thanks,
-- Lars
13 years, 9 months
buildiso not creating pxe menu correctly for non redhat breeds
by Michael Hoffman
Hi all,
I noticed that cobbler sync builds all of the pxe environment. This
part works with all of the currently defined breeds correctly and
creates the proper pxe menu for each. (substitution ks with autoyast,
jumpstart, etc). However, it appears that the cobbler buildiso does
that is suppose to build an iso pxe environment does not. It looks like
the code used to build the correct pxe menus is not in the buildiso code
base. Has work begun on merging to the 2 code bases so that sync and
buildiso use the same pxe building code?
Thanks,
--
Michael Hoffman <michaelchoffman(a)gmail.com>
Michael C. Hoffman
13 years, 9 months
FreeBSD support: explicit support for chaining bootloaders?
by Douglas Kilpatrick
To do automated installs of FreeBSD, I've needed to setup cobbler to
chain to the FreeBSD pxeboot loader. FreeBSD has a concept of "kernel
vars" instead of a command line, and the pxeboot loader knows how to set
them. This allows for ipappend equivalent functionality.
So far, I've gotten this working by putting pxeboot.bs (extension
required by pxelinux) in as the "kernel" of the distro. But then I
don't have any place to put the kernel. And I've got a initrd
(mfsroot.gz) as well...
Suggestions on how to resolve this? Is there interest in just another
parameter added that most users would ignore? Suggestions for a better
way to handle it?
Doug
--
Doug Kilpatrick
kilpatds(a)oppositelock.org
13 years, 9 months
koan: use virt-install instead of virtinst library?
by Cole Robinson
Hi all,
I'm the primary virt-install/virtinst developer. I'd like to make a
recommendation that koan switch away from using the virtinst library and
just calling out to the virt-install command.
Basically virtinst as a library is crap :) It really became an API by
historical accident. I'm considering in the future discontinuing it's
public API status and just moving it wholesale into the virt-manager
codebase (but it's a low priority and I would make sure all API users
could cope before making that change).
If koan just called out to the virt-install command, and even did
something like virt-install option passthrough via the koan CLI, you
would immediately gain the benefit of all upstream virt-install work.
I'd also say virt-install is an even more stable API then virtinst is:
far more people out there have old virt-install scripts that need to
keep working, but virtinst has only a handful of users and the primary
ones (virt-manager and virt-install) change with it in lockstep, so API
back-compat breakage is a real possibility, though we obviously try hard
to avoid it.
Any thoughts? Possible problems I didn't consider?
Thanks,
Cole
13 years, 9 months
Cobbler API use in 'new style' triggers
by Eric Raymond
Hello All,
I have been working with Cobbler for a while now, and I am more familiar
with XMLRPC/remote function. I am now working on a few projects that
require post install triggers. I have read through the documentation, and
found it sparse, confusing, and just not working for me.
I am trying to build a simple trigger in
/usr/lib/python2.6/site-packages/cobbler/modules called
install_post_noreload.py. It simply adds a string to the ksmeta field for
the system, so if it somehow reboots, it will only reload the OS, and not
blow away the data drive. I thought this would be a simple task, but all i
have run into are problems. I have tried implementing XMLRPC from the
remote scripts as if it were on another system, also tried to use the API
functions, but have gotten strange errors, that the API was missing _config.
All the simple examples from the Cobbler API reference page do not work for
me.
Can anyone suggest the quickest and most efficient way to go about editing
system profiles like this? I am running 1.6.8.
Thanks in advance!
Eric
13 years, 9 months
pxe localboot fix for HP proliants
by Vreman, Peter
There are problems with recent versions of syslinux and HP Proliants failing to LOCALBOOT (the HP Proliants hang after pxelinux).
Below is a workaround that works. Instead of using:
label localboot
localboot 0
you need to use:
label localboot
com32 chain.c32
append hd0
This workaround is written in http://syslinux.zytor.com/archives/2009-February/011532.html
Can the default cobbler pxe templates be adapted to use the chain.c32 approach?
Regards,
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
13 years, 9 months
More patches for cobbler.
by Bill Peck
I have some more patches for cobbler which I would like to get
upstream. Some add new features others make it a little more robust.
If you don't like any of them let me know what I can change to get them
accepted. :-)
[PATCH 1/6] Added new remote method clear_logs. Clearing console and
anamon logs in %pre is too late if the install never happens.
[PATCH 2/6] add X log to anamon tracking as well.
[PATCH 3/6] When adding in distros/profiles from disk don't bomb out if
missing kernel or ramdisk. just don't add it.
[PATCH 4/6] show netboot status via koan. This is really handy if you
have a system which fails to pxe boot you can create a service in
rc.local which checks the status of netboot and
calls --replace-self for example.
[PATCH 5/6] Changes to allow s390 to work. s390 has a hard limit on the
number of chars it can recieve.
[PATCH 6/6] Some systems don't reboot properly at the end of install.
s390 being one of them. This post module will call power reboot
if postreboot is in ks_meta for that system.
13 years, 9 months
