Duncan posted on Fri, 01 Jul 2011 11:26:58 +0000 as excerpted: > Patrick Lauer posted on Fri, 01 Jul 2011 11:45:16 +0200 as excerpted: > >> [Keeping an up and running system during a reinstall is] not as easy >> as it could be.
> Can't disagree there. =:^) ... And upon further thought, can't disagree with the first part, either. I've seen people untar a stage tarball over top and have it work for recovery, but that was with a generally uptodate system in any case, so dropping in a current stage3 generally replaced existing files. You're very correct about portage getting confused if the existing packages are outdated, since the tarball would be dropping in untracked files. At least in the past, portage wouldn't unmerge glibc or the like, but it certainly WOULD leave the untracked cruft around. It's not stage tarball related but I once had to deal with recovering from the loss of a /usr/ partition so when I loaded the backup partition, /usr/ and / and /var/ weren't in sync any more, meaning the package database was unsynced. /That/ was an interesting thing to recover from, involving lots of manual equery belongs loops and tracking down whether orphaned files were deletable or something eselect or the like handled... over time as various weird bugs showed up because something was using the untracked crufty version instead of the new one. So I KNOW what the results of that unmanaged cruft can be! (My resulting policy is to keep /, most of /var/, and most of /user/ on the same partition, everything that portage touches. So if I have to fallback to backup, it might be dated, but at least portage's database will be in sync with what's actually installed.) (I'd have simply skipped this to avoid the noise only it was unfinished business where I knew I was wrong and hadn't said so, and therefore bothering me greatly. Now I can sleep properly again! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
