Thanks everyone for the tips. I restored the backup successfully (it's actually fast and easy when done properly - I spent more time thinking what the right order is than the actual restore itself).
Looking back, the best way probably is to restore /etc and /home from backups after a minimal install (nothing selected in tasksel during installation), and only then aptitude install everything. One must only be careful with PAM: my configuration uses a few PAM modules that are not installed by default, so I could end up locking myself out of the system if I only restore /etc but don't install the other required PAM modules in the same login session (even so, it might still happen than some of the installation scripts will fail if PAM initially denies access to the daemon users). Well, that's a possibility I really didn't want to check... Since I wanted to clean up my config (I've been tracking Lenny long before it became stable, so I missed all changes to the default config from package maintainers), I went the etckeeper route: - minimal Lenny install - aptitude update after first boot - installed etckeeper and initialized the /etc repo - batch-install everything via aptitude - cloned the repo, cp -a the previous config from backup in the clone repo (since a restore with rdiff-backup would have deleted the repo directory) - edited the new config files, cherry-picking some nice new defaults from the package maintainers (together with my changes) - merged the cloned repo back to the original in /etc - restored the other backups (/home, /usr/local, GRUB's menu.lst) - rebooted to the fully restored system Well, the reboot was actually broken: cron and syslog-ng wouldn't start, and init dropped me to an emergency shell since e2fsck was unable to run (it found the partitions already mounted, so it couldn't check them). This was due to the parallel booting, it seems the symbolic links were not sanely restored (I haven't yet understood why), but dpkg-reconfigure insserv fixed that, and the system is fully functional now. Jesús M. Navarro" <jesus.nava...@undominio.net> wrote: > Now, your restore process created some users which turned > out with different UIDs because it needed. Don't give it > the chance to need creating those users and you'll be OK. > How can you acomplish that? Easy: just restore /etc/[passwd, > group, shadow, gshadow] *BEFORE* the "xargs aptitude install" > step. This way, by the time a package needs certain user it > will find it already there with the proper UID/GID. Right. I wasn't sure back then, but it was the only reason I could think of. Now I have the confirmation from etckeeper, most numerical ids are different now from the previous ones. > You could restore the whole /etc tree before the aptitude step > too. It certainly will ask what to do with conflicting files > but it's just a matter to always choose the option "retain edited > version" (or something to that meaning) which is the default option, > so it's a matter of ENTER,ENTER,ENTER,ENTER... Indeed, keeping the customized version of the config files is the default, so ENTER would suffice (about 800 times :). An "export DEBIAN_FRONTEND=noninteractive" before aptitude install should produce the same result (I didn't try, but that's what the debconf docs say). Best regards, Laurentiu -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org