Hi Anas, following is a list of feature request (yes, a lot :-)) that we missed during installing a very heterogenous network of 60 hosts with SuSE 9.0. Maybe some of them can make into the next version :-) 1) One cannot specify the disk option for lilo.conf. This is very bad if you have a host with scsi and ide disks and want to boot from the scsi disk. 2) You cannot take over the paket selection that is saved from yast2 as selection file for autoyast. They are incompatible and must be edited manually. Main difference seem to be the version numbers in the file saved from yast2, while autoyast only uses the paket names without versions. Maybe one can add an option in yast2 to save paket selection for autoyast. Usually when you get a new SuSE version, you edit the paket selection on a test host with yast2, save it, and then want to insert it into your autoyast files... 3) It would be nice if you could include special kernel packages to be used outside of the general package repository, just like you could in autoyast1. That's because we often change the kernel to be used to the latest release from SuSE, but we would like to keep our install source unchanged, i.e., keep the 1:1 copy from the DVD as install source and just add a special kernel in some other directory. This was nice how it was done in autoyast1/ 4) Something like this would be nice in rules.xml: <karch> <operator>or</operator> <match>k_deflt</match> <match_type>exact</match_type> </karch> <karch> <operator>or</operator> <match>k_athlon</match> <match_type>exact</match_type> </karch> <result>...</result> for e.g. selection the same kernel package for k_deflt and k_athlon architectures. But it is not possible, because one cannot specify <karch> twice with "or". 5) Please bring back that fstab-search feature :-) It was one of the most powerful things autoyast1 could do. Now I have to create a partition profile for each host from the existing fstab (we have about 20 different partition configurations) and add all of them info the rules file. To tell autoyast "leave everything as it was if you find a fstab and just format / and /boot" was a great feature... 6) I would like to specify a rule without condition in rules.xml. Reason is to add a general profile from which all hosts start, and then add extension by testing certain conditions. But for a starting profile, no condition is needed. This would also make it easier to keep the profiles small. You could have a profile file containing all the scripts, one for all the network stuff, and then just add a few profiles in rules.xml without condititions. Sth. like - add general profile - add scripts profile - add network profile - now start to add some stuff conditionally... 7) The script feature again: It would be very nice if you could find a way to allow external scripts to be called directly from autoyast. This would help, because now you write post-install scripts, test them, edit them, then insert all the code into an xml file. Now, sth. goes wrong, you test again, and now the danger is that the script code in the xml file and the external script get inconsistent easily. Autoyast1 user to have that $I- Variable, pointing to the install source, so we just had created a SCRIPTS subdirectory unter the suse dir from the install source, and called all the scripts from there. Would it be difficult to add such a reference variable/tag in autoyast2, too? So that you can do anything on the install source, like call the scripts? 8) When using several profiles in rules.xml, it would be nice if you could specify in every profile (or with every tag) what should be merged and what should be overwritten. Sometimes you might want to redefine the whole <network> section, sometimes you might only want to add a second interface. So, e.g. sth. like <networking> <redefine> <dns> ... </dns> </redefine> <add> <interfaces config:type="list"> <interface> .. </interface> </interfaces> </add> </networking> should overwrite *all* dns specications used before, but *add* the interface specifications to all the interface stuff defined before. This would be very powerful, but I guess it would be hard to implement... 9) An easy way to add general includes would be nice. The entity include mechanism does not work in rules.xml. As we have to specify about 40 partition rules (depending on the IP and the type), we would like to use a separate file for this and include it to keep rules.xml small. 10) It would be nice if the value matched in a <match> tag in rules.xml could be referenced in the result section. Then one could e.g. match the IP in the match tag and use "profile-$ip.xml" as result. So with one rule you could add a special profile for each host by just adding a file "profile-xxx.xxx.xx.xxx.xml" in the profile subdir. 11) A match variable for hostname would be nice. It is available from dhcp, so it would be nice if you could match it. Yes, I know, a long list :-)) However, it is not that we don't like AY2 here at all ;-) It resolved many of the problems that we had with AY1 and we really like the new features. However, some of features above would greatly enhance it :-) cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *