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 type. 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. Thanks.
