I'm about to re-install my main workstation with 9.1 pro. The current system started out as a 7.2 system, which was updated to 8.0 and then 8.1. So it's not even a 'clean' 8.1 system, since it is still running lilo, lprng, and sendmail, which have since been superceded in the default selection list. Over the years, I've gone back to the disks or FTP site and added more .rpms to the mix many times. It's time to start fresh with a clean install, but I'd like to save the time and agravation of going back to the disks over and over as I discover the needed packages. I've heard of something called AutoYast, but I've never used it, and the admin manual doesn't mention it. Is there a way I can get yast to write a file containing a list of all installed packages, and hopefully a backup of all configuration files I've edited manually? (Yast's 'system backup' seems to backup the changed files, so that's a start. It also selects lots of manpage files, which I know I haven't edited, so I suspect that it's comparing with the original system install, and picking up files relpaced by YOU as well. But I see danger in running 'restore system' on 9.1 with a backup made under 8.1) Hopefully in a format that yast can read to at least add to the default package selection list? And produce a 'checklist' of config files that I'll have to examine? I remember back in the days of yast1, there was a 'save config' and 'restore config' option as part of the initial install, but I don't find that anywhere in yast2, and my recollection is that it just backed up the current selection list, not the aggregate of everything that had been selected in multiple executions of yast. So what I'm looking for might do something like this: rpm -qa > backup_selection_file yast's 'system backup' selecting changed files which are part of installed rpms edit backup_selection_file stripping off version numbering, leaving only package names. In YaST: provide a function to merge the backup_selection_file into the package selection list, and invoke the dependency resolution code to flag conflicts (grub vs lilo, postfix vs sendmail, etc.) ...and produce a file containing package names that do not exist in the new distribution, for later resolution by searching the sdb with 'what became of...? type questions. AHA! I just discovered that yast's 'system backup' facility also generated a file named 'autoinst.xml' which appears to contain not only the package list, but also the user list and some other configuration info. But I still haven't found out how to get YAST to read this file. ...then after the install is complete, I have the system backup archive to go thru manually, as I do the .rpmnew and .rpmold files after each YOU cycle. I wonder: Does SuSE do any market research to determine what packages its customers really use? How do they develop the 'default' package selectoin list? They get some feedback by seeing what packages are downloaded from the FTP version, but from watching this list, it appears all too common for people to mirror the entire FTP site, then install only a subset, which would water down the usability of that info. WHat if someone published a script that would `rpm -qa`, diff that with yast's default selection list, and mail it to a robot that would collect statistics on which packages are actually installed in the field? ...or maybe the same statistics could be developed if YOU sent the results of `rpm -qa` along with some hash that would attempt to uniquely identify an installation as part of its exchange? Actually, I use fou4s more often than YOU. Marcus, you wanna collect some stats as part of fou4s? I've been asking for several years, without success, for the ability to re-use the directory of patches downloaded by YOU or fou4s to update other machines locally. Is it so difficult to save the files downloaded in a directory structure that mirrors the ftp site? Please, allow YOU or fou4s to specify a cache to be checked locally via ftp or nfs, or on a mounted CDROM, before spending the bandwidth again to download from the SuSE mirror. I support several machines that are either modem-connected or off-net altogether. It would be nice to be able to keep them updated as well. I was thinking that my system update would be just the first task I'd tackle today. Here the better part of the day is gone, and I don't yet even have a clear plan how to accomplish it! -- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin