[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Various kickstart 9 issues.

I am looking for assistance in getting the following Kickstart RH9 issues
resolved.  First some history.

I have been working with Kickstart since RH 6.1.  And have had to provide a
number of fixes to each release for my purposes.  Over time the releases
have caught up with my fixes so that very few are necessary.

Fix #1:  I only do network install using pxe and monitor through a serial
port remotely (I cannot remember the last time I did a CD install).  I would
argue that most of us doing this use an xterm per machine to monitor the
installs.  The problem is that the installer assumes vt100 if using serial
and it is ugly.  Since 6.1 I have be replace the vt100 terminfo file in the
initrd image with xterm.  Now it looks great, just like the VGA and all the
keys work.  I think that kickstart should using vt call query the terminal

Problem.  With RH9 somewhere it gets reverted back to ugly.  Almost like the
terminfo file does not get read or is read from another source.  I am
assuming a .img file from the NFS server.  I am still looking for it.

Fix #2:  Since I always monitor through the serial port and all I do is
build headless high performance Linux Clusters I have no need for the mouse.
The "mouse none" directive to this date is ignored by kickstart and kudzu
still probes for serial mice hosing my beautiful serial screen.  I have two
patches for this for all RH distros.  The first is to change packages.py to
use kudzu -qs, then to fix the screen trash at the end of the install I
replace list = kudzu.probe... to list = None in site-packages/rhlp/mouse.py.

Potential problem.  What if I do want a mouse for some reason.  I would like
to see an alternative to this patch, or for kickstart to honor the "mouse
none" directive in my kickstart file, or for RH to not probe for serial mice
if using console=ttyS....  So far I have had no problems with my patches.

Fix #3:  Not a RH issue.  Some machines with Fiber adapters will catch them
before the onboard in a probe.  This is because the hardware has priority
for the adapters over the onboard.  This can be a problem with unattended
automated installs where the Fiber is used for SAN.  You can (and some have)
hose your SAN by installing the OS on it because it was detected first.  I
stage2.img and the initrd image I remove the qla.* entries from pcitable to
avoid this.

Potential problem.  What if I want to install the OS on the fiber?  I would
like to see kickstart options that allow you to ignore some devices (e.g.
nodevice qla.*) during install, or a directive to force the install on a
type of device.

Future kickstart feature requests:

1.  A daemon that is started on the node during install that will allow a
remote administrator in an automated fashion to request the current status
of the install.  This would be helpful when installing 1000s of nodes.  I
will do the work if someone will tell me where to put the code.

2.  Usermode kickstart.  I would like to install a new OS on an unused
partitions while the OS is running.  Then after all the nodes have the new
image, update grub to boot the new partition then reboot the cluster.  If I
do not like the new image I and always boot back.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]