Thank you for your help. This worked wonderfully. However, once the install is complete I have /dev/hda6 and /dev/hda7 as my /boot and / partitions. Not that it's a huge issue, but to keep things clean I would obviously like to have these on /dev/hda1 and /dev/hda2. Is this because it uses /dev/hdax during the installation and can't make/mount those while the install is running? One more thing: When using the AutoYast utility to include a postinstall script, it embeds the shell script in the xml file and has a blank <location> tag, and does not run. What's the recommended way to do this? I tried specifying the <location> of the script (full path + script name), however, this didn't work either. Thanks for your help! Warren On Thursday 18 May 2006 16:39, warren@leetnet.com wrote:

I tell the server the path to my autoyasttest.xml and everything looks great until it goes to partition/format/mount the drives. It's saying it cannot format hda6, however it shouldn't even be looking at or creating an hda6.

it seems that you hit a bug in SLES9SP3 autoyast gets confused by the "max" on the primary partition. Either remove the "max" and replace it by a size (like "10GB") or remove the <partition_type>primary</partition_type> or specify <partition_type>primary</partition_type> for all partitions. There is a bug in the "max" calculation in SP3 :(

...

Thank you for your help. This worked wonderfully. However, once the install is complete I have /dev/hda6 and /dev/hda7 as my /boot and / partitions. Not that it's a huge issue, but to keep things clean I would obviously like to have these on /dev/hda1 and /dev/hda2.

try to add <partition_type>primary</partition_type> to all partitions in the profile then.

If I do this, I lose my ability to use the max size for / partition because of the autoyast bug as discussed earlier. Is there any way around this? I haven't tested partition_nr yet with size max, would this work or would that hit the bug as well?

After the installation, you can find a log about the scripts run in /var/adm/autoinstall/logs (I should add the to the documentation).

Thanks for the great piece of info. I'm now able to find out where my script bails. It's during the make depend step of compiling ProFTPD 1.3, in which I get an error 127. If I don't run the postinstall script from autoyast, I can successfully run it once installation is complete with no problems. Any suggestions here? Again, thanks for your help and the great site documenting autoyast. Warren ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

I am having difficulty in getting my classes to merge together properly. (i have to duplicate entries to get them read or, re-order them causing other entries to be dropped, etc) I have a rules.xml file that does a custom script to snarf cmdline opts that define a SITE and a NODETYPE variable. From that, i get inclusion of 3 primary profiles: base.xml site-@custom1@.xml node-@custom2@.xml Within each of these files are some classes options that pull in other files from {conffiles}/classes/[Base|Site@custom1@|@custom2@]/ But, the resultant merged profile often has only partial data. and the y2log file shows that it didn't even bother to notice some of the class inclusions in the files above. (it does show that it processed the 3 primary .xml files). E.G. I have: <profile> ... <install> <classes config:type="list"> <class> <class_name>Base</class_name> <configuration>Host.xml</configuration> </class> <class> <class_name>Base</class_name> <configuration>UserDefaults.xml</configuration> </class> <!-- These above two fail to get incorporated or acknowledged in y2log --> <class> <class_name>Base</class_name> <configuration>Groups.xml</configuration> </class> <class> <class_name>Base</class_name> <configuration>Sysconfig.xml</configuration> </class> <!-- Several other intervening class files *DO* get read and merged --> <class> <class_name>Base</class_name> <configuration>Host.xml</configuration> </class> <class> <class> <class_name>Base</class_name> <configuration>UserDefaults.xml</configuration> </class> <!-- *BUT* if if i re-declare the exact same two failing class entries from the top, they NOW get read and merged here ?! --> (these duplicated lines weren't in the original file and y2log showed it never bothered to look for Base/Host.xml or Base/UserDefaults.xml) ... I can't find any documentation showing that classes need to be in a specific order or anything else, *BUT* one of the other files that has just 2 class inclusions works fine, but another with a single entry doesn't work, unless i include the exact same <class>..</class> entry 3 times!? Are there known issues with the classing system for this version? If so, any useful workarounds or debugging features that would help? thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdowdy@ucar.edu - http://www.ral.ucar.edu/~sdowdy/