hi guys and girls,
thanks for the many many offers to test the installer and installable tree's on the machines you already have and in roles that you would expect to use the distro in.
However, rather than manual installs - we all gain by being able to automate these runs using kickstarts; so consider writing kickstarts for your tests. There are some examples here : https://nazar.karan.org/cgit/bluecain/tree/ ; clone the git repo with "git clone git://nazar.karan.org/testing/bluecain"
Here is what needs doing : - Write a kickstart file that would either install an existing system[1] - Write a bash shell script that can be run on the machine, which would do some tests and exit with '0' if all goes well. - Please name the kickstart file in a way that it ends in .cfg - Please name the test script exactly the same as the kickstart file but ending in .sh
Here is what happens: - When the distro tree is in place the kickstart would be used to run through an install. - Once the install is done, the machine or vm will reboot - post reboot, an ssh connection is made to the installed machine or vm, with the test script being ssh'd over. - test script is run, and hopefully exits with 0
Feel free to contribute against centos4 or 5 or 6 (or common ones ) for bare metal installs and Xen installs - we dont have kvm capability in there as yet ( but we should in the next few weeks ).
And don't forget to add your name to the Authors file. git submit via git-email to this list would work.
Thanks,
- KB
On Thu, Jan 6, 2011 at 6:36 PM, Karanbir Singh mail-lists@karan.org wrote:
hi guys and girls,
thanks for the many many offers to test the installer and installable tree's on the machines you already have and in roles that you would expect to use the distro in.
However, rather than manual installs - we all gain by being able to automate these runs using kickstarts; so consider writing kickstarts for your tests. There are some examples here : https://nazar.karan.org/cgit/bluecain/tree/ ; clone the git repo with "git clone git://nazar.karan.org/testing/bluecain"
Here is what needs doing :
- Write a kickstart file that would either install an existing system[1]
- Write a bash shell script that can be run on the machine, which would
do some tests and exit with '0' if all goes well.
- Please name the kickstart file in a way that it ends in .cfg
- Please name the test script exactly the same as the kickstart file but
ending in .sh
If I may suggest? Please put in the following '%post -nochroot' script.
%post -nochroot /bin/cp /tmp/ks.cfg /mnt/sysimage/root/ks.cfg
On RHEL 6, you should end that with a '%end' statement.
This preserves your downloaded ks.cfg in your built system's /root/ directory, for reference and comparison to the derived anaconda-ks.cfg. This is particularly important if you're like me and use multiple '%post' sections for distinct post-install operations.
Here is what happens:
- When the distro tree is in place the kickstart would be used to run
through an install.
- Once the install is done, the machine or vm will reboot
- post reboot, an ssh connection is made to the installed machine or vm,
with the test script being ssh'd over.
- test script is run, and hopefully exits with 0
Feel free to contribute against centos4 or 5 or 6 (or common ones ) for bare metal installs and Xen installs - we dont have kvm capability in there as yet ( but we should in the next few weeks ).
And don't forget to add your name to the Authors file. git submit via git-email to this list would work.
Thanks,
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 01/07/2011 01:41 AM, Nico Kadel-Garcia wrote:
Here is what needs doing :
- Write a kickstart file that would either install an existing system[1]
- Write a bash shell script that can be run on the machine, which would
do some tests and exit with '0' if all goes well.
If I may suggest? Please put in the following '%post -nochroot' script.
%post -nochroot /bin/cp /tmp/ks.cfg /mnt/sysimage/root/ks.cfgOn RHEL 6, you should end that with a '%end' statement.
Sounds good. Why dont you go ahead and contribute the relevant kickstarts and the test scripts.
This preserves your downloaded ks.cfg in your built system's /root/ directory, for reference and comparison to the derived anaconda-ks.cfg. This is particularly important if you're like me and use multiple '%post' sections for distinct post-install operations.
would make for an easy scripted test :)
- KB
On Sun, Jan 9, 2011 at 8:42 AM, Karanbir Singh mail-lists@karan.org wrote:
On 01/07/2011 01:41 AM, Nico Kadel-Garcia wrote:
Here is what needs doing :
- Write a kickstart file that would either install an existing system[1]
- Write a bash shell script that can be run on the machine, which would
do some tests and exit with '0' if all goes well.
If I may suggest? Please put in the following '%post -nochroot' script.
%post -nochroot /bin/cp /tmp/ks.cfg /mnt/sysimage/root/ks.cfg
On RHEL 6, you should end that with a '%end' statement.
Sounds good. Why dont you go ahead and contribute the relevant kickstarts and the test scripts.
This preserves your downloaded ks.cfg in your built system's /root/ directory, for reference and comparison to the derived anaconda-ks.cfg. This is particularly important if you're like me and use multiple '%post' sections for distinct post-install operations.
would make for an easy scripted test :)
- KB
I'm actually doing such testing right now for RHEL 6. I'd welcome access to installation components, even alpha release components, for PXE installing CentOS 6.
On 01/09/2011 06:42 PM, Nico Kadel-Garcia wrote:
would make for an easy scripted test :)
I'm actually doing such testing right now for RHEL 6. I'd welcome access to installation components, even alpha release components, for PXE installing CentOS 6.
The kickstarts and test scripts would run as a part of the centos-build process, apologies if that was not clear. So what you need to do is actually write out the kickstarts, their test scripts and submit a patch against the git repo url'd earlier.
let me know if you have any specific questions about that process.
- KB
Hi,
On Friday, January 07, 2011 12:36:53 am you wrote:
Here is what needs doing :
- Write a kickstart file that would either install an existing system[1]
- Write a bash shell script that can be run on the machine, which would
do some tests and exit with '0' if all goes well.
- Please name the kickstart file in a way that it ends in .cfg
- Please name the test script exactly the same as the kickstart file but
ending in .sh
Attached a kickstart file that is known to work with Scientific Linux 6 alpha.
As well as a kickstart file with a software RAID1 configuration that throws an error with Scientific Linux. The exact same disk layout does work with Centos 5.5, so submitting it as test case.
Hi Floris,
On 01/11/2011 01:39 PM, Floris Bos wrote:
Attached a kickstart file that is known to work with Scientific Linux 6 alpha.
As well as a kickstart file with a software RAID1 configuration that throws an error with Scientific Linux. The exact same disk layout does work with Centos 5.5, so submitting it as test case.
thanks for this - it helps.
Its quite good to have test cases, where failure of a process to complete is the test itself ( so a test success is based on a process or expected failure ).
the scripts are going to need a bit of editing before we can put them into an automation, I intend to work with Fabian to get that done and setup along with a feedback loop - so there is a reporting mechanism that shows what the outcome from the last test set was.
- KB
-
Floris Bos -
Karanbir Singh -
Nico Kadel-Garcia